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

Альберт Бертяков

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

Но, увы, количество многообещающих стартов, имевших широкое паблисити, отнюдь не всегда равняется количеству успешных финишей, «засвеченных» прессой. К тому же тщательный анализ показывает: об успешном завершении проекта зачастую объявляют совсем не те, кто некоторое время назад с помпой сообщал о старте. То есть завершаются, конечно же, все проекты, но завершаются они с разными степенями успеха — вплоть до полных провалов. И еще один парадокс: есть масса желающих рассказать о причинах своих успехов и совсем никого, кто стремился бы поведать миру о собственных ошибках и просчетах.

Затевая разговор о «подводных камнях» проектов по внедрению систем электронного документооборота (СЭД), необходимо определить рассматриваемое подмножество проектов.

Речь не пойдет о так называемых «моментальных проектах» — таких, все содержание которых состоит в установке в CD-дисковод компакт-диска с лицензионным (дай-то Бог!) программным обеспечением и запуском инсталляционой программы с принятием всех настроек по умолчанию. Фаза «внедрения» в таких случаях редко продолжается дольше недели — и то лишь в том случае, если с первой попытки что-то не связалось, а времени прочесть руководство по установке у сисадмина-«внедренца» сразу не нашлось. Правда, и живут такие системы ровно столько, сколько сохраняется интерес к ним все того же сисадмина. До конечных пользователей, реально нуждающихся в автоматизации операций с документами, такие системы почти никогда не добираются — в лучшем случае с ними поиграют две-три недели в ИТ-подразделении.

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

Теперь перечислим основные характеристики проектов, о которых пойдет речь.

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

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

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

Чтобы проблему решить, ее сначала нужно создать

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

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

Во-первых, ОРД — это приказы, распоряжения, протоколы, поручения и т. п. Иными словами, это документы, с которыми работают преимущественно руководители среднего и высшего звена управления. Если инициатор проекта внедрения СЭД — бизнес-руководитель, то толчком к началу проекта часто является его желание непременно избавиться от вороха бумаг, которые приходится просматривать и визировать (а зачастую еще и подолгу искать куда-то завалившуюся очень нужную бумажку). Если же инициатива исходит со стороны ИТ-службы, то здесь нередки случаи, когда превалирует стремление ИТ-людей продемонстрировать руководству свою нужность — продемонстрировать на максимально близком расстоянии от объекта «наносимой пользы».

Во-вторых, автоматизация ОРД на подсознательном уровне не воспринимается заказчиком как потенциально дорогостоящий, «долгоиграющий» и проблемный проект. Зачастую такой проект рассматривается в качестве тренировки перед чем-то действительно серьезным — например, созданием электронного архива проектно-конструкторской документации или автоматизацией процесса подготовки крупной инвестиционной сделки.

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

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

На Западе реализация ИТ-проектов и выбор программной платформы, на базе которой проект будет реализовываться, часто осуществляется с привлечением внешних консультантов. Для принятия адекватного решения о том, что именно (бизнес-процессы) и каким образом (СЭД) автоматизировать, необходимо эти бизнес-процессы обследовать и эту систему (возможно, и не одну) на них «примерить». У нас такая практика тоже постепенно завоевывает право на существование, но пока еще только на проектах, традиционно признаваемых «тяжелыми», — на ERP-проектах и комплексных интеграционных ИТ-проектах, когда необходимо «скрестить» в интересах заказчика сразу несколько систем, охватывающих различные сегменты бизнеса. К сожалению, платить деньги за советы по выбору системы электронного документооборота российский заказчик пока не готов. И проблема не только и не столько в скупости заказчиков, но еще и в том, что заказчики испытывают сомнения (нередко, увы, обоснованные) в объективности рекомендаций внешних консультантов. Ведь ИТ-консалтингом и внедрением ранее рекомендованных к приобретению систем занимаются одни и те же компании.

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

Краткая систематика проблематики

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

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

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

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

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

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

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

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

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

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

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

Проблема третья. «Монстр кастомизации»

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

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

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

Проект внедрения становится гораздо более дорогим. Если проанализировать бюджет типичного проекта внедрения СЭД, легко заметить, что на кастомизацию уходит от 50 до 80% всего бюджета.

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

Проблема четвертая, заключительная для данной статьи, но далеко не последняя. «Недопроект»

Помните, была такая присказка в советские времена: «Курица — не птица, Болгария — не заграница»? С таким же легким пренебрежением зачастую относятся к проектам внедрения СЭД руководители компаний, в которых подобные проекты выполняются.

Некоторые полагают: «Подумаешь, движение и учет бумажек автоматизировать... Зачем управляющий комитет проекта создавать, бизнес-спонсора назначать, вести все работы по «взрослой» проектной методологии? Руководить проектом поставим начальника канцелярии, в помощь ей выделим системного администратора — все равно целыми днями в серверной просиживает. Глядишь, за месяц управимся».

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

Рано или поздно проект внедрения СЭД в любой компании завершается. Возможны три варианта его завершения — успех (в разной степени, но все же...), неуспех (не будем о грустном) и прекращение (как с ремонтом).

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