Журнал о системах электронного документооборота (СЭД)
Внедрение электронного документооборота

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

  8 комментариев Добавить в закладки

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

Ещё материалы автора
Похожие записи
Комментарии (8)
Наталья Храмцовская 23 мая 2012 г. 21:12  

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

Ольга Суэтина 24 мая 2012 г. 13:30  

Цикл Деминга, назван по фамилии американского ученого (http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BC%D0%B8%D0%BD%D0%B3,_%D0%A3%D0%B8%D0%BB%D1%8C%D1%8F%D0%BC_%D0%AD%D0%B4%D0%B2%D0%B0%D1%80%D0%B4%D1%81), также известен как PDCA-цикл (Plan-Do-Check-Act: Планируй-Делай-Проверяй-Действуй)

 

Ольга Звонарева 24 мая 2012 г. 15:37  

Огромное спасибо за высказанное мнение к моей статье! Публикуюсь здесь впервые и мнение экспертов для меня очень важно!

Спасибо Вам, Наталья! Если бы знала, что будете на Docflow, непременно подошла и познакомилась лично. Несколько лет назад, общаясь с Вами в ЖЖ,  Вы мне очень помогли.

По поводу терминов, я тоже была несколько озадачена, потому сразу и полезла в словари изучать:-)

Спасибо за перепубликацию Андрею Колесову!

Перечисленные термины сама впервые услышала!  И переписала:-)

 

 

Ольга Подолина 25 мая 2012 г. 10:31  

В этом обзоре я не нашла то, что оказалось для меня самым ценным в обсуждении. Когда говорили о том, как избежать  разрастания объема проекта, прозвучало предложение:"Последним этапом ставить разработку техзадания на развитие проекта". Вот это- реальное решение!

   "Каждый заказчик к концу проекта резко умнеет и начинает наконец понимать, что же ему нужно"- это народная мудрость консультантов-внедренцев.

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

  Да, давайте развивать системы, но  заказчик не должен требовать увеличенных  объемов работ за первоначальные деньги.

 

По поводу Деминга. На основе книг Деминга разработана современная теория менеджмента качества. ИСО 9000 - все оттуда. И японский менеджмент основан на его принципах(можно найти в интернете- "14 принципов Деминга").  Есть Ассоциация последователей Деминга , на их сайте множество материалов http://www.deming.ru/

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

В общем, там много интересного.

Ольга Звонарева 25 мая 2012 г. 20:22  

Обращаясь к Ольге Подолиной.

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

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

Спасибо за информацию о деминге. Непременно найду.

И... хорошо нашим рук-ям бы перенять подход японцев:-)

Ольга Подолина 28 мая 2012 г. 10:40  

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

Об этом я написала в статье "Как выбрать СЭД" - а выбор зависит от  "уровня ECM-зрелости" организации.См. http://www.ecm.i-teco.ru/index.php/publications/article/45-2011-11-17-08-43-52

Т.е Вашей организации предстоит пройти эту ступеньки.:-))

  К сожалению,формат проведения Круглого стола на Docflow не подразумевал возможности высказывания мнений из зала..

Мой опыт показывает, что главная причина неуспеха проекта- это попытка "перепрыгнуть" через уровень зрелости, внедрить то, к чему организация еще не готова.

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

 

Ольга Подолина 28 мая 2012 г. 10:59  

Да, и уже вижу единомышленников. В PC WEEK была статья http://www.pcweek.ru/ecm/article/detail.php?ID=139191 "ЕСМ-не самоцель, а средство повышения эффективности бизнеса".

 Там тоже говорится о модели зрелости, причем применяют модель на основе разработок Gartner.

Я за основу брала модель зрелости CMMI (Capability Maturity Model Integration)-эволюционная модель развития способности компании разрабатывать программное обеспечение.

 

Сейчас обсуждают
Евгений Кочуров 20 марта 2017 г. 07:49  
Юрий Зерин 18 марта 2017 г. 19:18  
Сергей Бушмелев 15 марта 2017 г. 22:47  
Елена Истомина 15 марта 2017 г. 13:08  
Сергей Бушмелев 15 марта 2017 г. 10:46  
Больше комментариев