Хорошо забытое старое. Выпуск V

Между предыдущей моей статьей, опубликованной в «Хорошо забытом старом», и публикуемой сейчас прошло 6 лет. Это не значит, что все эти 6 лет я ничего не писал или не писал ничего заслуживающего внимания. Писал – но на другие темы, не про СУД/СЭД, ECM и т.п., а про электронный бизнес, ИТ-консалтинг, ИТ-аудит, управленческий консалтинг… Возможно, пару-тройку своих статей этого периода я тоже когда-нибудь опубликую здесь.

За это время (1998-2004) в мире и в стране случились Интернет-бум и Интернет-«бум-м-м», «порталомания» (о ней я напишу скоро) и «ERPизация», появилось понятие «ECM», а компанию Documentum купила корпорация EMC…

В эти годы (в конце 2000-го, если быть точным) возникла компания «Документум Сервисиз», в которую мне – еще не скоро, но неизбежно – предстояло прийти на работу.

Название компании, в которой я работал, за эти 6 лет менялось два раза, но в нем каждый раз сохранялся фирменный корень «TopS»: сначала это был «eTopS Consulting», а потом (и до настоящего времени) – «TopS Business Integrator». Смены названий отражали изменения бизнес-фокуса акционеров и руководителей, а для меня это означало переключение на какой-то новый, наиболее актуальный – с точки зрения рыночной востребованности - фронт деятельности. Но все эти годы самым любимым направлением оставалось управление документами – как бы его ни называли в угоду заказчикам, аналитикам рынка и журналистам-популяризаторам. И даже когда я не занимался этим направлением активно, я продолжал отслеживать происходящие изменения - выход новых продуктов, уход с рынка заслуженных ветеранов, слияния и поглощения вендоров, успехи и неудачи проектов.

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

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

Наверное, это одна из лучших статей, написанных мной. Сейчас, перечитывая ее при подготовке к публикации в блоге, я понял, что написать многие куски в ней лучше, чем они уже написаны, я не смог бы… Единственное, что я, наверное, смог бы, если бы писал эту статью еще раз – это описать не 4 проблемы внедрения, а штук 20-30. Потому, что в то же самое время, когда эта статья была опубликована, в моей жизни начался самый сложный, самый длинный, самый проблемный и, в общем-то, самый успешный мой проект – внедрение системы Documentum (точнее, бизнес-решения на базе этой системы) в ФСК ЕЭС. Я отдал этому проекту полтора года своей жизни и нервов, и я обязательно напишу о нем здесь – когда придет время и когда я сам пойму, о чем хочу рассказать.

Четыре пробемы внедрения СЭД

(Журнал «Директор информационной службы», № 5, 2004 год)

Не все проекты одинаково проблемны

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

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

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

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

• Мы не будем говорить о так называемых «моментальных» проектах – т.е. таких, все содержание которых состоит в установке в CD-драйв диска с лицензионным (дай-то Бог!) ПО и запуском инсталляционой программы с принятием всех настроек по умолчанию. Фаза «внедрения» в таких «проектах» редко продолжается дольше недели – и то, лишь в том случае, если с первой попытки что-то не связалось, а времени прочесть руководство по установке у сисадмина-«внедренца» сразу не нашлось. Правда, и живут после «внедрения» такие системы ровно столько, сколько сохраняется интерес к ним все того же сисадмина. До конечных пользователей, реально нуждающихся в автоматизации операций с документами, такие системы почти никогда не добираются – в лучшем случае, с этой системой могут «поиграть» две-три недели сотрудники ИТ-подразделения.
• Мы также не будем обсуждать «бесконечно-самостройные» системы, которые полностью – от постановки задачи до практической реализации (почти никогда не достигаемой) – создаются внутри организаций. Но не просто внутри организаций, а внутри ИТ-подразделений организаций, когда и постановкой задачи, и анализом процессов документооборота, и программной разработкой занимаются ИТ-специалисты. Проекты такого рода часто превращаются в бесконечное наращивание программистских «бантиков» во второстепенных функциях системы, бесконечное тестирование новомодных технологических «примочек», бесконечное шлифование пользовательского интерфейса… Единственный «конечный» объект в этом процессе – собственно, конечный бизнес-пользователь – оказывается не просто «на обочине» процесса, он оказывается лишним, путающимся под ногами, камнем преткновения на пути в светлое программистское будущее…

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

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

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

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

1.        Какая первоочередная задача чаще всего формулируется в качестве требующей решения в проекте внедрения СЭД? 

Мы не сильно ошибемся, если станем утверждать, что не менее, чем в 75% случаев это автоматизация организационно-

распорядительного документооборота (ОРД). Почему так происходит? Ведь очевидно, что по классической теории управления

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

Соответственно, оптимизация и автоматизация этих процессов в лучшем случае приведет к некоторому снижению накладных

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

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

документооборота именно с «ОРД-старта»? Причин несколько, и большинство из них является субъективно-психологическими:

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

 2.        Как осуществляется выбор программной платформы для проекта СЭД? 

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

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

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

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

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

Вот о проблемах и пойдет наш разговор.

Проблема первая. «Гиперпсевдосайентификация». 

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

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

Представьте картину: начальник канцелярии, ветеран с министерским прошлым, способный практически с закрытыми глазами зарегистрировать и разослать документы по назначению, смотрит на «картинки», где прямоугольниками, ромбами и стрелками изображено то, чем он занимается ежедневно в течение многих лет. И при этом ничего в этих «картинках» не понимает… А ведь ему, как представителю заказчика, необходимо подписаться под техническим заданием или техпроектом, в котором эти схемы и присутствуют. Боясь признаться в своем недопонимании современных консалтинговых методологий, начальник канцелярии подписывает ТЗ и акт завершения обследования… Час его сладостной мести (и начало кошмаров для внедренцев) придет чуть позже, когда исполнителям нужно будет уже не рисовать наукообразные схемы, а реализовывать в системе особенности процессов именно этой канцелярии, «перегибать» стандартные алгоритмы под привычки вполне конкретного клерка, потому что:

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

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

 

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

Общеизвестно, что одно из первых утверждений, с   которым ERP-консультанты приходят к заказчику, гласит: «Система не 

позволяет автоматизировать неэффективные бизнес-процессы». Именно поэтому «классика» ERP-консалтинга подразумевает,

 что при внедрении системы вслед за описанием процессов «как есть» обязательно следует описание «как будет», т.е. 

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

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

проектам автоматизации ОРД:

• ОРД не относится к процессам основной цепочки добавления стоимости (в отличие от процессов, охватываемых ERP-системой);
• ОРД является одной из наиболее консервативных сфер бизнес-деятельности любой организации.

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

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

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

• Кастомизация делает исходную систему менее стабильной, поскольку качество кастомизационного программного кода (разрабатывающегося зачастую под «дамокловым мечом» проектных сроков) уступает базовому коду.
• Кастомизация делает исходную систему менее производительной, поскольку дополнительный программный код является надстройкой над базовым кодом, что приводит к неизбежным издержкам времени исполнения программы.
• Кастомизация – и это главное! – делает проект внедрения гораздо более дорогим. Если проанализировать бюджет типичного проекта внедрения СЭД (а автор и сам такие бюджеты разрабатывал, и бюджеты сторонних проектов в руках держал), легко заметить, что на кастомизацию уходит от 50 до 80 процентов всего бюджета.
• Кастомизация дает и заказчику, и исполнителю ложную уверенность в том, что сделать с системой можно что угодно. Главное – найти подходящую функцию и сконструировать подходящую визуальную форму. И «притягиваются за уши» СЭД с возможностями кастомизации к реализации проектов из совершенно неподходящих сфер жизни. Вот то, что микроскопом гвозди забивать в принципе можно, но не нужно, все знают и понимают. А вот то, что с помощью классических СЭД не нужно, например, создавать систему обработки заказов или организовывать финансовый документооборот, очевидно далеко не всем. Ведь, в принципе, средства кастомизации СЭД позволяют построить и такие решения…

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

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

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

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

Рано или поздно проект внедрения СЭД в любой компании завершается. Возможны только три варианта его завершения – успех (в разной степени, но все же… И тогда пресс-релизы, success stories, фото на обложку ИТ-журнала…), неуспех (не будем о грустном…) и прекращение (как с ремонтом в собственной квартире…).

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