Специфика ECM-проектов глазами заказчиков

Автор: Андрей Колесов
Когда мы говорим о ECM-проектах (Enterprise Content Management, управление корпоративным контентом), то этот термин уже сам по себе подразумевает значительный размер информационной системы предприятия (по числу пользователей, по спектру решаемых задач, по объемам информации и пр.), что в свою очередь существенным образом влияет на все этапы жизненного цикла проекта, включая выбор ECM-платформы, ее внедрение и эксплуатацию. В преддверии февральской конференции “Экосистема ЕСМ: от платформенного вендора до корпоративного заказчика” мы попросили экспертов из числа заказчиков — представителей государственного и коммерческого секторов рынка — поделиться своими соображениями относительно специфики реализации ECM-проектов.

Выбор поставщика решения

“Для любого органа государственной власти и для любой госкомпании основным механизмом отбора, естественно, будет конкурсная процедура”, — четко формулирует базовый принцип начальник управления сопровождения прикладных систем департамента информационных технологий ФГУП “Российская телевизионная и радиовещательная сеть” Антон Бурлаков. Далее он подчеркивает, что основным критерием конкурсного отбора выступает не цена, а репутация участников конкурса, подтвержденная успешно реализованными проектами аналогичной или близкой тематики. Уже потом следуют такие характеристики, как ценовое предложение, наличие сертифицированных специалистов, предполагаемые сроки реализации и ряд других факторов. Но кроме формальных показателей учитываются неофициальные аспекты, в частности очень важен общий информационный фон вокруг каждого потенциального реализатора проекта.

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

Заказная разработка на универсальной платформе или готовое специализированное решение?

Понятно, что выбор в значительной степени зависит от конкретной бизнес-задачи и от уже существующего ИТ-ландшафта предприятия. Отталкиваясь от этого тезиса, рассуждает Антон Бурлаков: “Естественно, что универсальная платформа предпочтительнее, но любая универсальность имеет границы. Факторов тут множество, от цены до перспектив интеграции. Есть еще один важный аспект — сроки внедрения и как следствие — возможность полномасштабной разработки заказного решения. Вполне работоспособный вариант — готовое решение с определенной кастомизацией, но тут вероятен пересмотр бизнес-процессов. Вот как раз их надо трогать в самую последнюю очередь”. В любом случае, считает он, конкретный проектный вариант должен быть определен уже на этапе формирования функционально-технических требований, но может быть скорректирован как в результате анализа предложений поставщиков, так и в процессе погружения в вопрос и трансформации требований.

Надежда Брукк говорит, что выбор в пользу универсальной мощной ECM-платформы в случае их проекта был сделан фактически изначально: “Мы хорошо знали спектр предложений и собственные задачи: сейчас на рынке просто не существует готовых продуктов, удовлетворяющих всем нашим требованиям. Далее на основе выбранной платформы было создано заказное решение”.

Кто должен быть внедренцем: сам разработчик или интегратор?

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

Антон Бурлаков говорит о том, что плюсы и минусы обоих подходов известны и выбор зависит от конкретной ситуации и проекта. Но при этом он считает, что в целом нужно делать ставку на классическую партнерскую модель, и в таком случае проблема выбора внедренца заключается в том, какого именно интегратора выбирать — местного масштаба или федерального уровня. Для городов-миллионников проблема такого выбора не очень актуальна, а в других местах ситуация требует, по его мнению, работы именно федерального интегратора: “Показателен опыт тиражирования крупных систем по модели “центр — филиалы”, когда приходится изыскивать ресурсы на местах и это не всегда удается. Очень хорошо зарекомендовали себя крупные интеграторы федерального уровня с развитой филиальной сетью. Интеграторы, территориально оторванные от площадки внедрения, — очень большое зло, даже при наличии самых современных средств связи. Командировки с соответствующим режимом работы, удаленный доступ и прочие прелести как-то незримо накладывают свой отпечаток. Опыт прихода региональных интеграторов на московские площадки (в результате конкурсных процедур и откровенного демпинга) при отсутствии в Москве серьезного представительства и постоянного штата на моей практике никогда не был однозначно положительным”.

Оценки успешности проекта

Тут есть несколько последовательных вопросов, начиная с того, нужно ли проводить такие оценки, а если нужно — то как. Например, есть ли различия в оценке “успешности проекта по внедрению” и “успешности проекта по использованию”.

На последний вопрос Антон Бурлаков говорит однозначное “нет” и далее поясняет: внедрение по сути дела не имеет четких границ и не заканчивается на подписании акта о приемке системы в промышленную эксплуатацию. Есть проект, и у него есть жизненный цикл: инициация, выбор подрядчика, внедрение, эксплуатация системы, ее поддержка, модернизация, возможно трансформация, вывод из эксплуатации. Если же говорить об оценке успеха проекта в целом, то это можно делать по многим критериям, главным из которых будет степень соответствия системы возложенным на нее задачам и ожиданиям конечных функциональных пользователей. А скоростное внедрение с натяжками, приписками, закрытием этапа “под елочку” и бодрой success story только на первый взгляд может показаться успешным. “Поэтому, повторюсь, оценивать успех какого-то одного этапа проекта в отрыве от остальных ни в коем случае не следует”, — подчеркнул он.

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

Опубликовал: Александр Абрамов (info@ict-online.ru)

Тематики: Интеграция, ПО

Ключевые слова: ECM