Опыт решения типичных проблем при внедрении СЭД. Мнения экспертов с круглого стола DOCFLOW 2012.

Приехав на выставку в середине дня, успела на самое интересное для себя мероприятие – круглый стол с обсуждением актуальной темы «На ошибках учатся. Опыт решения типичных проблем при внедрении СЭД».

В круглом столе принимали участие представители видных компаний-заказчиков СЭД и известные компании-производители: СК «Альянс», «Роснано-информ», «Сбербанк технологии», «Сургутнефтегаз», «ABBYY Россия», «DIRECTUM-M», «ЭОС» и др.

Было обозначено пять ключевых вопросов для обсуждения:

1. Технические и организационные сложности, с которыми приходится сталкиваться во время внедрения.

2. Что чаще всего становится причиной превышения бюджета проекта?

3. Низкий уровень пользовательской поддержки внедряемых технологий.

4. Внутриполитический вопрос. Как быть, если внутри организации есть несколько центров влияния и назревает конфликт интересов?

5. Опыт борьбы с разрастанием объема проекта.

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

Итак, терминология:

Сайзинг (англ. sizing – классификация) решения.

Определение необходимого и достаточного уровня производительности внедряемой (или уже эксплуатируемой) системы.

Вендор (англ. vendor продавец, торговец) — юридическое или физическое лицо, являющееся поставщиком товаров и услуг, объединенных торговой маркой.

Пилотный проект (англ. pilot project) пробный, экспериментальный, реализованный для изучения положительных и отрицательных сторон в целях дальнейшего принятия решения о целесообразности широкого внедрения.

Транзакция (англ. transaction — сделка, урегулирование спора путем соглашения сторон) - единица коммуникативного процесса (социального взаимодействия), состоящая из коммуникативного стимула и коммуникативной реакции (напр., вопрос-ответ).

Цикл Деминга - циклически повторяющийся процесс принятия решения, используемый в управлении качеством.

Скоуп (англ. scope – объем, масштаб) проекта (коммерческое предложение). Требования к программному обеспечению - совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.

Облачные решения – иными словами, возможность работы в удаленном доступе, используя Web-браузер. Работа в облаке означает, что вы не тратите время и ресурсы на поддержку собственных серверов, при этом обеспечивается существенно более высокий уровень надежности, сохранности данных.

Технические и организационные сложности, с которыми приходится сталкиваться во время внедрения

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

Говоря далее о технической и организационной стороне вопроса, изначально необходима детальная проработка бизнес-процесса – разработка технического задания (ТЗ) и определение стоимости – суммы, которую заказчик готов выложить за программу.

Опыт участников круглого стола говорит о том, что в этом деле экономия, например, на серверной части, не уместна, учитывая дальнейшее увеличение нагрузки на нее. И в этой связи исполнителю будет не лишним провести мониторинг внутренней сети компании.

В разработке ТЗ важна четкая конструктивная формулировка задач. Расплывчатые требования только стопорят процесс. 80% успеха внедрения СЭД определяет совместная работа над ТЗ, детальная проработка всех аспектов.

Исполнителю, безусловно имеющему больший опыт и знания, целесообразно самому начать выстраивать программу внедрения.

Один из участников обсуждения сравнил внедрение СЭД с ремонтом в квартире, который невозможно закончить.

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

Если речь идет об уже упомянутых холдинговых компаниях, то в ТЗ должное внимание должно уделяться не только этапам внедрения программы в головном офисе, но и отдельно должен быть прописан порядок подключения к программе всех холдинговых структур.

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

Что чаще всего становится причиной превышения бюджета проекта?

Говоря об увеличении бюджета, участники круглого стола сошлись во мнении: как правило, это обусловлено изменением требований к программе. Или же изначально неправильным подсчетом общей суммы. И здесь, главным образом, вина компании-исполнителя.

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

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

Кроме того, любой документооборот – это, прежде всего, процессы движения документа. Одной из распространенных ошибок является неполное, поверхностное описание этих процессов в ТЗ.

Неожиданным, но оправданным советом прозвучало мнение экспертов о проведении предварительного анкетирования для того, чтобы понять – кто он - твой заказчик. С кем придется столкнуться в перспективе внедрения.

Результаты бывают самыми неожиданными. К примеру, в результате одного такого исследования выяснилось, что изменений в организации документооборота желает только руководящий состав компании, а рядовых специалистов устраивает текущий порядок в соотношении 50% на 50%.

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

Таким образом, резюмируя, вопрос увеличения бюджета, на практике выясняется – типовых решений в процессе внедрения СЭД практически не бывает. И обеим сторонам нужно быть готовым к любым изменениям в системе электронного документооборота и поправкам бюджета.

Результат голосования – вновь позиция «частично».

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

В самом начале обсуждения третьего вопроса о низком уровне поддержки пользователей одним из экспертом был приведен известный казус, случившийся на бельгийской железной дороге во время внедрения электронной системы управления финансовыми документами.

После предупреждения руководством о том, что такого-то числа система будет запущена в работу, половина сотрудников под самыми разными предлогами не вышли на работу. Такими болезненными бывают нововведения!

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

Поскольку такие казусы бывают неизбежны, необходимо вести диалог с руководством. А сотрудникам наглядно и неоднократно демонстрировать возможности программы, ее плюсы. Важно убедить людей в том, что программа станет помощником в решения текущих производственных задач, а не источником неприятностей.

Так же противниками внедрения СЭД, как показывает практика, бывает IT-отдел, на чьи плечи, безусловно, ложится двойная нагрузка и отдел безопасности.

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

Как быть, если внутри организации есть несколько центров влияния и назревает конфликт интересов?

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

Внедрение программы затронет все структуры компании заказчика и здесь важно дать понять людям, что их мнение не обходят стороной, к ним прислушиваются. И, безусловно, вести конструктивный диалог с руководителями проекта внедрения.

Еще одним достоверным примером наиболее безболезненного внедрения СЭД, было предложение «довести» сотрудников компании до горячего желания внедрить или поменять действующую систему. Не секрет, что многие компании используют самые первые разработки «электронной канцелярии», которые со временем перестают решать актуальные задачи производственных процессов.

И, резюмируя эту тему, эксперты озвучили необходимость закрепления процесса перехода к электронному документообороту в распорядительном документе, что послужит еще одним стимулом ослабления сопротивления со стороны сотрудников.

Опыт борьбы с разрастанием объема проекта

Проблема разрастания объема проекта так же является достаточно актуальной. Для того чтобы препятствовать этому, мало четко прописать скоуп проекта в ТЗ, но важно внести в проект дальнейшие пути развития проекта. Это позволит на время затормозить бесконечность процесса внедрения электронных систем управления бизнес-процессами и документооборотом.

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

Однако в итоге было высказано справедливое наблюдение: если заказчик захочет, чтобы компания-исполнитель сделала еще что-то, значит он (исполнитель) хорошо выполнил свою работу. Иными словами, обеим сторонам всегда есть к чему стремиться.

Другим решением вопроса может быть деление проекта внедрения на подпроекты.

Исходя из практики, озвученной экспертами, крупные холдинговые компании даже привлекают сторонние консалтинговые компании на тех или иных этапах внедрения.

Еще одним решением задачи было пожелание предлагать заказчику готовые типовые решения, исходя из большого опыта компании-исполнителя.

Результат голосования в финале обсуждения пятого вопроса вновь вернулся к позиции «частичной» актуальности услышанного.

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

Оригинал опубликован на docmanagement.livejournal.com