Проблемы внедрения средств электронного документооборота

Реферат

по дисциплине Документирование управленческой деятельности

на тему

Проблемы внедрения СЭД

Введение

Проблема внедрения новых средств электронного документооборота (СЭД), так же как и проблема их стандартизации бесспорно актуальна в нашей стране. Это, пожалуй, самое актуальное направление рынка Информационных Технологий. Российский сегмент рынка документооборота на данный момент оценивается в 160 тыс. долларов, на рынке присутствуют около 50 компаний и постоянно появляются новые. Каждая компания занимается решением проблемы внедрения СЭД и все вместе пытаются прийти к консенсусу по поводу стандартизации СЭД.

Цель этой работы – показать обнаруженные проблемы внедрения СЭД и подытожить результаты поиска их стандарта.

1. Проблемы внедрения средств электронного документооборота

В данной главе представлены проблемы внедрения СЭД с точки зрения директоров двух крупнейших представителей российского рынка систем документооборота: ABBYY Software House и Электронные Офисные Системы.

1.1 Классификация проблем с точки зрения компании ЭОС

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

Проблема первая. «Излишнее наукообразие»

Итак, проект начинается, и начинается он с консалтинговой «классики» с обследования и описания бизнес-процессов, подлежащих автоматизации. Именно здесь, на старте проекта, внедренцы зачастую допускают ошибку, которая закладывает мину замедленного действия под весь процесс внедрения. Речь идет о широко распространившейся практике формализованного описания бизнес-процессов с использованием нотаций типа IDEFx, ARIS или UML. Нельзя отрицать принципиальную полезности инструментов такого рода в крупных проектах, предусматривающих разработку или настройку сложных программных систем. Однако применение формальных нотаций в проектах по автоматизации ОРД — когда речь идет, как правило, о подстройке типового программного продукта под особенности процессов документооборота конкретного заказчика — можно охарактеризовать давно знакомым и родным «из пушки по воробьям». Представьте себе следующую картину. Начальник канцелярии, ветеран с министерским прошлым, способный практически с закрытыми глазами зарегистрировать и разослать документы по назначению, смотрит на «картинки», где прямоугольниками, ромбами и стрелками изображено то, чем он занимается ежедневно в течение многих лет, — и ничего в этих «картинках» не понимает. А ведь ему, как представителю заказчика, необходимо подписаться под техническим заданием или техпроектом, в котором эти схемы и присутствуют. Боясь признаться в своем непонимании современных консалтинговых методологий, начальник канцелярии подписывает ТЗ и акт завершения обследования. Час его сладостной мести (и начало кошмаров для внедренцев) придет позже, когда исполнителям нужно будет уже не рисовать наукообразные схемы, а реализовывать в системе особенности процессов именно этой канцелярии, «перегибать» стандартные алгоритмы под привычки вполне конкретного клерка, потому что:

· он так привык работать в течение многих лет;

· работая так, он обеспечивает своего руководителя всеми необходимыми бумагами точно в срок;

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

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

Проблема вторая. «Сопротивление среды и реинжиниринг наоборот»

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

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