
ECM-«грабли»
Игорь
Пичугин
,
независимый эксперт
,
экс-iOne
Президент ассоциации 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 >>>
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Комментарии
23.10.2015
Любопытно про "Поршневую" дипломатию. Не смог найти что имеется в виду.