1. 19 мая 2015 Москва, Рэдиссон Славянская www.docflow.ru
Экспресс-аудит соответствия СЭД
Александр Родионов,
Директор департамента систем управления
документами ЗАО «ЛАНИТ»
Москва, 2015 г.
3. Требования руководства к системе формализованы и система
им соответствует
Совокупные затраты на внедрение и развитие системы
оправдали ожидания руководства
Эффект от внедрения системы оправдал ожидания руководства
Система соответствует «отраслевым» стандартам и политике
государства в области информатизации
Стоимость ежегодных платежей по технической поддержке
системы соответствует ее ценности для компании
Вы уверены, что система способна поддержать рост вашей
компании с точки зрения количества пользователей и сложности
бизнес-процессов
Есть примеры из жизни? Что хотелось бы добавить?
Удовлетворенность руководства
4. Пользователи системы удовлетворены скоростью работы
системы
Пользователи системы считают интерфейс СЭД понятным и
удобным
Все обоснованные функциональные требования пользователей
к системе удовлетворены
Пользователи умеют работать в системе и инструкции отвечают
на их вопросы
Пользователей устраивает скорость реагирования технической
поддержки на их вопросы
Внедрение системы действительно позволило сократить
обращение бумажных документов
Внедрение системы действительно позволило снизить
трудоемкость работы с документами
Есть примеры из жизни? Что хотелось бы добавить?
Удовлетворенность сотрудников
5. Система соответствует IT-стратегии компании и полностью
использует ее преимущества
Система отвечает требованиям IT-безопасности
Система является масштабируемой и настраиваемой под Ваши
потребности
Система имеет понятный и описанный интерфейс интеграции со
сторонним ПО
Техническая документация на систему является качественной
Вас устраивает объем внутренних IT ресурсов, которые
затрачиваются на сопровождение системы
В договоре технической поддержки содержится четкий SLA,
дающий заказчику действенные рычаги воздействия на
поставщика в случае нарушения сроков и качества оказываемых
услуг
Есть примеры из жизни? Что хотелось бы добавить?
Удовлетворенность IT
6. Вендор регулярно поддерживает контакт и сообщает о новостях
План развития системы понятен и соответствует планам
компании на систему
Условия работы с вендором (ценовая политика, пакеты услуг и
т.д.) понятны и прозрачны
Вендор занимает уверенную позицию на рынке и его
финансовая стабильность не вызывает сомнений
Вендор быстро реагирует на изменение законодательства,
появление новых технологий и периодически выпускает
обновления
Компания-внедренец имеет опыт реализации сопоставимых по
масштабу проектов на выбранной платформе
Сотрудники компании-внедренца компетентны и вы
удовлетворены общением с ними
Есть примеры из жизни? Что хотелось бы добавить?
Надежность поставщика
7. Что интересно поставщику решений кроме ваших денег? Чужие деньги!
Возможность референс-визитов
Выступление клиента не семинарах/выставках
Рекомендации коллегам по отрасли
Публикации в прессе
Как дать обратную связь (критику) так, чтобы она была услышана и правильно
воспринята:
Нам в вашей системе очень нравится (краткий список того, что из
критериев было оценено высоко), хотелось бы добавить (то, что вы хотите
изменить).
«Пользователи отмечают понятный интерфейс системы и хорошее
быстродействие, хотелось бы добавить уверенности в том, что при
расширении количества пользователей и процессов мы сможем все это
сохранить».
Самый страшный вопрос клиента – это тот, который он не задал. Говорите со
своими подрядчиками.
Как построить разговор с поставщиком
Самый худший сценарий – когда при внедрении СЭД мнение высшего руководства не удосуживаются узнать вообще. Есть общее понимание, более-менее стандартное, по целям и задачам проекта, но мнения руководства напрямую никто не спросил.
Как правило, требования собирают на уровне канцелярии, но именно руководство является спонсором проекта, принимает решение об успешности проекта и эффективности внедрения.
Требования руководства и сотрудников иногда могут кардинально отличаться и есть риск получить не то, что ожидалось. Пользователь думает об удобстве и фишечках для себя, а руководство мыслит масштабнее, его интересует влияние внедрения на бизнес – сокращение затрат, оптимизация процессов, повышение эффективности и т.д….
Так в одной крупной энергетической компании мы столкнулись с постоянным потоком пожеланий на доработки, сертификацию, аттестацию подсистемы безопасности и долго согласовывали требования на них, но 1 поход к IT-директору расставил все точки на «i», так как это шло вразрез с видением направлений развития СЭД, а также планами по бюджету.
Также надо не забывать, что к интерфейсу и устройству, на котором хочет работать руководство, могут предъявляться специфические пожелания. Так в одном крупном органе госвласти мы столкнулись с большим количеством пожеланий к дизайну и функционалу Мобильного рабочего места.
Про рост… В этом году мы завершили замену ранее внедренного коробочного продукта одного из отечественных разработчиков СЭД в одном химическом комбинате, именно по причине понимания со стороны руководства, что СЭД не сможет поддержать дальнейшее развитие и выдержать требуемое количество документов и процессов.
Конечно, важна и оценка эффекта от внедрения, но в текущий момент нет 100% работающих методов перевода в деньги эффекта от внедрения…
Зачастую функциональность, удобство и понятность не всегда присутствуют в одном решении. Сами функции могут требовать специальных знаний (например, поиск с использованием спецсимволов) или могут быть зарыты так глубоко, что пользователь их или не находит вовсе или тратит на выполнение операций бесконечно много времени.
Не менее значимым является современность интерфейса в части перекликания с офисными приложениями.
Новый, красивый и продуманный интерфейс значительно повышает не только скорость работы, но и лояльность пользователей к системе.
Особенно стоит обратить внимание на удобство и простоту поиска информации в системе.
В функциональных требованиях тоже надо найти разумную грань.
С одной стороны, внедренцы часто жалуются, что на этапе внедрения часто поступает очень большое количество требований или совсем неоправданных даже с точки зрения реальных процессов Заказчика, или не позволяющих решению «взлететь». И мы действительно часто наблюдаем это. Например, когда один из подрядчиков пытался безуспешно запустить мобильный клиент в крупной энергетической компании, хотя понятно было, что запланированный к реализации функционал по работе с конфиденциальными документами они не потянут.
С другой стороны, большинство требований действительно оправданы с точки зрения бизнеса заказчика, но предлагаемое решение, часто коробочное, под него не адаптируется, платформа не подразумевала доработку или у компании-внедренца нет компетенции для его доработки.
Иногда, при выборе системы ориентируются только на интерфейс, а потом уже понимают, что за ним ничего нет и по факту большинства необходимой функциональности просто нет, а доработать ее не возможно.
Как правило внедрение системы не только позволяет снизить кол-во бумажных документов, но и позволило существенно оптимизировать процессы работы с ними и накладные расходы, особенно если взять территориально-распределенные системы.
Обязательным требованием должна быть масштабируемость, при том же и в количестве клиентских мест, и процессов, и объема документов.
Любая современная система должна вписываться в ИТ инфраструктуру компании и позволять реализовывать сквозные процессы, предполагающие объединение разрозненных систем с целью исключения дублирования ввода информации и бесшовной интеграции, без необходимости разработки самих средств интеграции. Здесь стоит говорить именно о средствах и внешнем API, а не готовых «коннекторах» между системами, так как в большинстве случаев системы кастомизируются, тогда «коннекторы» не подходят на все 100% и тоже требуют доработки.
При поддержке самая главная ошибка – это ее отсутствие или невозможность обеспечить должное качество. Как показывает практика. Без должной поддержки система просто умрет.
Использовать инсорсинговую или аутсорсинговую стратегию при поддержке и развитии системы - остается на усмотрение самой компании, но на выбор влияют объем необходимых ресурсов и их квалификация, а как следствие и стоимость.
При использовании аутсорсинга главное четкий SLA.
Часто наблюдаем, когда в договорах ТП:
размытые формулировки описания услуг;
нет конечных сроков устранения инцидентов (указано только время первой реакции);
нет единой точки входа для Заказчика,
нет отслеживания процесса рассмотрения инцидентов, т.е периодического информирования о ходе работ по устранению инцидента, возможности эскалации,
увеличенное время решения инцидентов, в случае поддержки не от вендора или не от официальных партнеров.
Например, в одной компании мы столкнулись с тем, что договор между вендором и компанией, обеспечивающей поддержку, содержал время на анализ и решение инцидентов, намного превышающие сроки в договоре Заказчика, о чем его, конечно, не предупредили.
Здесь стоит отметить, что важны не только вендоры, но и компании-внедренцы: их опыт, количество сопоставимых по масштабу внедрений.
Отдельно всегда стоит понимать насколько поставщик может влиять на развитие самого решения и вендора при развитии платформы, иначе все ваши планы по развитию могут так и остаться планами.