СЭД: Лучше один раз попробовать, чем сто раз пожалеть

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

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

Итак, какие шаги можно предпринять?

Тестирование до покупки

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

Один из возможных вариантов - обучить только ключевых сотрудников, желательно охватив все автоматизируемые подразделения. Эти же сотрудники потом будут играть роль «нулевой» линии поддержки, за которую разработчик ПО скажет огромное спасибо и благодаря которой стоимость поддержки для заказчика может существенно снизиться. Кстати, обучение тоже имеет смысл оценивать: стоимость, длительность, качество подачи, достаточно ли доступно для сотрудников. Это навскидку, в приоритете иногда могут быть и другие стороны.

Пилотный проект

Еще вариант: сделать маленький проект, закрывающий небольшую задачу с небольшим числом пользователей, чтобы сделать стоимость и сроки минимальными. Слов написал мало, но это не значит, что пилот – это просто. :) Пилотные проекты от остальных отличаются только масштабом.

Тестовая эксплуатация (ТЭ)

Здесь я имею ввиду этап, когда ПО уже куплено, установлено, данные из старых систем сконвертированы, справочники настроены, и пользователи решают свои реальные задачи (а не тестовые, как до покупки) в режиме дублирования со старыми системами. Этот этап позволяет дать наиболее полную, и как правило, уже окончательную, оценку применимости продукта. Следовательно, как и при тестировании, надо определиться, кто и как будет оценивать результаты ТЭ.

Важно к началу ТЭ иметь обученных сотрудников, которые смогут квалифицированно сформулировать критерии успешной ТЭ. Иначе ситуация будет такой же, как иногда с ТЗ на разработку системы: написать написали, но написанное может и не иметь отношения к действительности. Конечно, консультанты поставщика помогут с формулировками, но будет гораздо лучше, если представители заказчика планируют приемку тестовой эксплуатации с открытыми глазами.

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