Главный специалист ЭОС Елена Антошечкина об условиях успешности внедренческих проектов

В рамках крупнейшей отраслевой конференции Docflow-2012 состоялся круглый стол, на котором приглашенные эксперты поделились своим видением необходимых условий для успешности внедренческих проектов. Мы попросили рассказать об этом поподробнее главного специалиста компании «Электронные офисные системы» (ЭОС), ответственного секретаря ПК 6 Елену Антошечкину, также принимавшую участие в этой дискуссии.

Елена, будьте добры, расскажите, что нужно сделать в первую очередь, чтобы проект внедрения оказался успешным?

- В первую очередь нужно обязательно «заложиться» на проведение такой работы как полноценное обследование компании-заказчика. И в нем должны принимать участие не только специалисты компании-исполнителя, но и компании-заказчика. Причем еще до начала самого обследования нужно его спланировать, обсудив с заказчиком, в каком формате тот будет принимать участие в работах. Крайне важно заручиться поддержкой заказчика и обеспечить его участие уже на первых этапах. Поэтому оптимальным вариантом в данном случае является создание рабочей группы, в которую будут входить как представители заказчика, так и представители исполнителя. Во-первых, это будет официальным подтверждением того, что заказчик  принимает участие в проводимых работах, и он впоследствии не сможет отказываться от каких-то принятых рабочей группой решений. А во-вторых, для остальных сотрудников и структурных подразделений заказчика решения, принятые рабочей группой, в составе которой находятся должностные лица соответствующего уровня со стороны заказчика, также будут обязательны к исполнению. Наша практика показывает, что со стороны заказчика в рабочую группу целесообразно включать руководителей, решение которых не оспаривается заказчиком – вряд ли высшего звена, поскольку это не их уровень, но среднего звена (например, руководителей IT-отдела, руководителей отделов профильных подразделений) - и специалистов, которые непосредственно будут проводить работы.

Кроме правильного определения состава рабочей группы, есть ли еще какие-либо нюансы при проведении обследования?

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

Далее следуют тонкости в непосредственной подготовке технического задания?

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

Наверное, успех зависит не только от первоначальной оценки, но и понимания реальной структуры компании, а не только возможностей головного центра?

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

А что говорит опыт ЭОС, ведь у вас существует множество реализованных проектов в крупных федеральных структурах, как выходили из положения они?

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

А что делать, если требуется модернизация региональной инфраструктуры?

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

Можете привести примеры реальных заказчиков, кто пошел по такому пути?

- Практически все крупные заказчики с распределенной структурой идут по пути автоматизации сначала центрального офиса, а потом регионов – это позволяет сэкономить средства на первом этапе автоматизации, проверить эффективность внедренного решения и максимально мягко (по срокам, финансам, комфортности для пользователей) подключить к системе удаленные структуры.

Елена, большое спасибо!

Опубликовал: Эльвира Муравицкая (info@spbit.ru)

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

Ключевые слова: электронный документооборот, ЭОС