Реферат
по дисциплине Документирование управленческой деятельности
на тему
Проблемы внедрения СЭД
Проблема внедрения новых средств электронного документооборота (СЭД), так же как и проблема их стандартизации бесспорно актуальна в нашей стране. Это, пожалуй, самое актуальное направление рынка Информационных Технологий. Российский сегмент рынка документооборота на данный момент оценивается в 160 тыс. долларов, на рынке присутствуют около 50 компаний и постоянно появляются новые. Каждая компания занимается решением проблемы внедрения СЭД и все вместе пытаются прийти к консенсусу по поводу стандартизации СЭД.
Цель этой работы – показать обнаруженные проблемы внедрения СЭД и подытожить результаты поиска их стандарта.
В данной главе представлены проблемы внедрения СЭД с точки зрения директоров двух крупнейших представителей российского рынка систем документооборота: ABBYY Software House и Электронные Офисные Системы.
Процессы документооборота традиционны и консервативны, и люди, давно и много работающие с документами, привыкли к этим процессам, сжились с ними и сами стали чуть более консервативными — по крайней мере, по отношению к содержанию и способу исполнения своих служебных обязанностей. А термин «внедрение», давно и устойчиво вошедший в лексикон ИТ-специалистов, именно по отношению к консерватизму работы с документами демонстрирует свою первобытно-брутальную, силовую семантику. Внедрение — это нарушение устоявшегося порядка вещей, слом привычных стереотипов, вторжение в тонкую материю бюрократических «сдержек и противовесов». Внедрение — это столкновение разных взглядов, разных привычек, разных манер поведения, разных приемов работы. А там, где происходит столкновение физических или метафизических субстанций, неизбежны проблемы.
Проблема первая. «Излишнее наукообразие»
Итак, проект начинается, и начинается он с консалтинговой «классики» с обследования и описания бизнес-процессов, подлежащих автоматизации. Именно здесь, на старте проекта, внедренцы зачастую допускают ошибку, которая закладывает мину замедленного действия под весь процесс внедрения. Речь идет о широко распространившейся практике формализованного описания бизнес-процессов с использованием нотаций типа IDEFx, ARIS или UML. Нельзя отрицать принципиальную полезности инструментов такого рода в крупных проектах, предусматривающих разработку или настройку сложных программных систем. Однако применение формальных нотаций в проектах по автоматизации ОРД — когда речь идет, как правило, о подстройке типового программного продукта под особенности процессов документооборота конкретного заказчика — можно охарактеризовать давно знакомым и родным «из пушки по воробьям». Представьте себе следующую картину. Начальник канцелярии, ветеран с министерским прошлым, способный практически с закрытыми глазами зарегистрировать и разослать документы по назначению, смотрит на «картинки», где прямоугольниками, ромбами и стрелками изображено то, чем он занимается ежедневно в течение многих лет, — и ничего в этих «картинках» не понимает. А ведь ему, как представителю заказчика, необходимо подписаться под техническим заданием или техпроектом, в котором эти схемы и присутствуют. Боясь признаться в своем непонимании современных консалтинговых методологий, начальник канцелярии подписывает ТЗ и акт завершения обследования. Час его сладостной мести (и начало кошмаров для внедренцев) придет позже, когда исполнителям нужно будет уже не рисовать наукообразные схемы, а реализовывать в системе особенности процессов именно этой канцелярии, «перегибать» стандартные алгоритмы под привычки вполне конкретного клерка, потому что:
· он так привык работать в течение многих лет;
· работая так, он обеспечивает своего руководителя всеми необходимыми бумагами точно в срок;
· ему ничего не стоит разок-другой припоздать с бумагами к шефу, сославшись на "эту дурацкую программу".
И здесь уже не пройдут аргументы исполнителей, что все сделано в соответствии со схемами в ТЗ. А казалось бы, чего проще — описать все процессы нормальным русским языком, ведь документооборот совсем не высшая математика.
Проблема вторая. «Сопротивление среды и реинжиниринг наоборот»
Общеизвестно, что одно из первых утверждений, с которым ERP-консультанты приходят к заказчику, гласит: «Система не позволяет автоматизировать неэффективные бизнес-процессы». Поэтому классика ERP-консалтинга подразумевает, что при внедрении системы вслед за описанием процессов «как есть» обязательно следует описание «как будет», то есть выполняется реинжиниринг с целью последующей автоматизации эффективных и оптимизированных процессов. И вслед за описанием «как будет» — реализация «да будет так». Но организационно-распорядительный документооборот в отличие от процессов, охватываемых ERP-системой, не относится к процессам основной цепочки добавления стоимости и является одной из наиболее консервативных сфер деятельности любой организации.
На практике это означает, что внедренцам СЭД зачастую приходится подстраивать систему под реалии традиционных процессов документооборота, то есть заниматься «реинжинирингом наоборот». Очень важно поэтому, чтобы программная платформа СЭД позволяла совершать подобное насилие над собой, будучи приспосабливаемой даже к самым неэффективным бизнес-процессам. А это, в свою очередь, пробуждает к жизни «монстра кастомизации».
Проблема третья. «Монстр кастомизации»
Большинство известных автору проектов внедрения СЭД, потерпевших неудачу, «умирали», не вынеся тяжести дополнительной прикладной разработки, которую внедренцы пытались взгромоздить поверх базовых средств системы. В кастомизированном интерфейсе только одно хорошо — он внешне выглядит так, как хочется заказчику. Все остальное в доработке плохо.
Исходная система становится менее стабильной, поскольку качество кастомизационного программного кода, разрабатываемого зачастую под дамокловым мечом проектных сроков, уступает базовому коду.
Производительность исходной системы падает, ведь дополнительный код является надстройкой над базовым кодом, что приводит к неизбежным издержкам времени исполнения программы.
Проект внедрения становится гораздо более дорогим. Если проанализировать бюджет типичного проекта внедрения СЭД, легко заметить, что на кастомизацию уходит от 50 до 80% всего бюджета.
Кастомизация дает и заказчику, и исполнителю ложную уверенность в том, что сделать с системой можно что угодно. Главное – найти подходящую функцию и сконструировать подходящую визуальную форму. И «притягиваются за уши» программные платформы с возможностями кастомизации к реализации проектов из совершенно неподходящих сфер жизни. То, что микроскопом гвозди забивать в принципе можно, но не нужно, все понимают. А вот то, что с помощью классических систем электронного документооборота не нужно, например, создавать систему обработки заказов или организовывать финансовый документооборот, очевидно далеко не всем. Ведь, в принципе, средства кастомизации СЭД позволяют построить и такие решения.
Проблема четвертая, заключительная для данной статьи, но далеко не последняя. «Недопроект»
Помните, была такая присказка в советские времена: «Курица – не птица, Болгария – не заграница»? С таким же легким пренебрежением зачастую относятся к проектам внедрения СЭД руководители компаний, в которых подобные проекты выполняются.
Некоторые полагают: «Подумаешь, движение и учет бумажек автоматизировать... Зачем управляющий комитет проекта создавать, бизнес-спонсора назначать, вести все работы по «взрослой» проектной методологии? Руководить проектом поставим начальника канцелярии, в помощь ей выделим системного администратора – все равно целыми днями в серверной просиживает. Глядишь, за месяц управимся».
Никто из руководителей подобных монологов не произносит. Но вот действия и руководящие решения, принимаемые во многих компаниях в части СЭД, являются наглядной иллюстрацией отношения к проектам автоматизации процессов организационно-распорядительного документооборота как к чему-то второстепенному.
Консерватизм сотрудников
Системы электронного документооборота (СЭД) имеют некую особенность: система либо должна быть внедрена повсеместно, на всех рабочих местах, связанных с созданием, редактированием и хранением информации, либо эффективность от ее использования будет минимальной. Такая постановка вопроса сразу выявляет одну из основных проблем внедрения: в любой организации найдутся люди, стремящиеся избежать чего-либо нового. Консерватизм персонала обычно обусловлен нежеланием обучаться и переобучаться, а также, возможно, низкой образованностью. Эта проблема может завести в тупик весь процесс внедрения. В особенности это касается организаций, в которых сама кадровая политика очень консервативна и никто, даже руководитель, не свободен в перемещении или обновлении кадров.
Как разрешать эту проблему? Работа с людьми – это всегда политика на уровне всей организации и психология на уровне конкретных людей. Во многих случаях требуется индивидуальный подход к каждому человеку, учет его особенностей — как возрастных, так и профессиональных и личных. Надо понимать, что люди годами привыкали к одному способу работы, а вы предлагаете резко переключиться на другой, совершенно им непривычный, причем не снижая нагрузку. Что можно сделать, чтобы облегчить людям этот переход?
Во-первых, переход можно сделать постепенным. Например, сначала внедрить только электронную почту. Модель работы электронной почты достаточно понятна, люди легко к ней привыкают. Затем можно построить несложную интранет-систему и постепенно приучать сотрудников организации искать необходимые им справочные материалы (номера внутренних телефонов, даты и повестки совещаний, протоколы, приказы, распоряжения, внутренние нормативные документы и т. п.) на внутреннем интранет-сервере. Благодаря этому люди понемногу привыкнут читать документы с экрана, работать с электронными документами, распечатывать только то, что нужно. Такой подход в любом случае сократит тиражирование бумажных документов, облегчит их обновление. Очень желательно (но, к сожалению, не всегда возможно), чтобы средства электронной почты и доступа к информации изначально являлись частями будущей системы документооборота. В этом смысле определенное преимущество предоставляет среда Lotus Notes, в которой указанные компоненты содержатся в базовой поставке. Если же вы установите, к примеру, почту на основе Outlook Express и SMTP/POP3-сервера, а потом — систему документооборота, в которой имеется интегрированный клиент, работающий по протоколу MAPI, то придется приучать людей к другому клиентскому ПО с его особенностями, переносить все существующие почтовые ящики из одной системы в другую и т. д.