ECM-«грабли»

Президент ассоциации AIIM Джон Манчини попросил группу ИТ-директоров, евангелистов AIIM, составить «лист болячек» — список тех моментов, о которых они хотели бы знать, но, к сожалению, не знали, когда в первый раз выполняли проект по управлению контентом. Список «граблей», на которые не стоит наступать, получился довольно обширным...

• Важно больше времени потратить на планирование завершения проекта, прежде чем запускать вендорскую рулетку.
• Необходимо больше думать о том, как лучше выполнить первый проект — не слишком сложный, но и не тривиальный.
• Больше времени на presale проекта старшему менеджменту компании, чтобы потом они могли помочь нам управлять изменениями.
• Документирование рабочих процессов — главный приоритет при обосновании затрат для любого внедрения. И чем шире вы разворачиваете эту работу, тем больше выгода.
• Необходимо сузить сферу (scope) первого проекта. Не надо стараться сразу объять необъятное.
• Чего не хватало? Анестезии — и тогда я не должен был бы делать ECM! Если серьезно, я хотел бы знать, что таксономии, как только их создаешь, тут же устаревают.
• Мы должны были более четко определить роли ИТ и бизнеса, чтобы ИТ выступали больше в роли продавца «облака» (внутреннего или внешнего), а бизнес устанавливал приоритеты и стратегию того, чем управляют.
• Прежде всего все, вовлеченные в проект, должны знать, что такое ECM: технологии, этапы проекта, какие можно получить преимущества и главное — какие изменения становятся результатом внедрения.
• Нужно было сосредоточиться на обучении пользователей, а не просто дать им новый набор инструментов, которые бы не требовали чрезмерно сложных записей и метаданных. Мы же направили пользователей по тернистому пути, который, в конечном счете, препятствовал принятию ими новой системы.
• Если вы заменяете устаревшую систему, остерегаетесь низкого качества данных! Мусор на входе — мусор на выходе. Если данные плохие, вы потеряете поддержку бизнеса, даже если сама система великолепна.
• Если у вас нет своих (in-house) экспертных знаний по ECM и вы не можете найти или у вас нет времени взять в штат кого-то с опытом внедрения ECM, наймите независимого консультанта, не связанного с вендором, который поможет определиться с дорожной картой и стратегией внедрения.
• Прежде чем выбрать вендора, четко определите свои бизнес-цели и задачи: для начала — зачем компании нужен ECM и чего вы хотите добиться с его помощью. Ваши high-level бизнес-требования, точки интеграции и ожидаемые результаты помогут сформировать для вендоров RFP (request for proposal) и определиться с тем, какую функциональность вы хотите видеть в продукте вендора.
• Не все содержимое нужно мигрировать в новую систему.
• Я бы сделал сайт для пользователей ECM. Это помогло бы понять, каким образом изменились рабочие операции, какие в этом преимущества и недостатки. Это бы позволило моей ИТ-команде контактировать с реальными пользователями и получать обратную связь от них, а не от вендора.
• Не забывайте о email! Ранние ECM-проекты в первую очередь имели дело с «документами», и только потом, возможно, в них была бы включена электронная почта. Но у наших клиентов email — основной рабочий инструмент (и хранилище, и workflow), поэтому его нужно включать в начальный объем проекта.
• Не обольщайтесь тем, что ваши пользователи умеют обращаться с инструментами, которые вы им дали. Я был удивлен, насколько всеобщим оказалось отсутствие у сотрудников основных умений и навыков в использовании инструментов для поддержки бизнеса.
• Приступая к внедрению, не забывайте об огромной кривой обучения всех пользователей системы. Совсем не лишним будет приобрести дополнительное обучение для персонала.
• После внедрения регулярно устраивайте встречи представителей ECM-вендора с пользователями системы. Таким способом можно исправить многие замечания и требования пользователей.
• Используйте «поршневую» дипломатию. Мы поставляем политику, инструменты и технологии, чтобы улучшить бизнес, его безопасность и управление рисками. Т.е. мы обеспечиваем решение для бизнеса, а не для отдела ИТ.
• Вендор должен общаться с пользователями через 30, 90 и 180 дней после внедрения, чтобы гарантировать, что они используют инструмент так, как предназначено.
• Регулярно, раз в две недели, проводимые ланч и семинар — это хороший способ сгенерировать вопросы и идеи со стороны пользователей, которые начали «играть» с системой. Это позволило бы определить содержание учебных курсов и новых проектов.
• Сначала запустите, потом оптимизируйте. Не надо гнаться за совершенным RFP в 200 с лишним страниц. Сохраняйте его простым, оживите и потом оптимизируйте.
• Фокус на правильной реализации (бизнес-)стратегии, а не технологии.

А что вы можете добавить к этому списку «болячек»? О чем вы жалеете, что не знали во время своего первого ECM-проекта? Пишите в комментариях и/или сразу по-английски на сайте AIIM >>>