Один из самых любимых публицистических жанров российского ИТ-рынка — кейсы, рассказы о реализации проектов. Правда, за таким термином как-то теряется из виду тот факт, что проектные описания, в свою очередь, делятся на две категории: “истории успеха” (success story) и “исследование дела” (case study). Между тем большинство наших кейсов относится к первой категории, хотя профессионалов интересуют “исследования”, которые рассказывают не просто о том, что получилось в результате, а о том, какой путь нужно было проделать и какие препятствия преодолеть для достижения успеха. И отдельный повышенный интерес — именно профессиональный, а не обывательский из жанра скандальной хроники —вызывают откровенные неудачи, о которых говорить публично просто не принято.
Организаторы состоявшейся в конце сентября конференции “DOCFLOW 2008 Санкт-Петербург” решили затронуть эту щекотливую тему, проведя интерактивную дискуссию “Проблемы в реализации СЭД-проектов”. Однако еще в ходе подготовки этого обсуждения с участием ряда экспертов стала понятна справедливость классической фразы “Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему” *. Проблема оказалась слишком многогранной, и потому было решено отказаться от классической схемы круглого стола (все участники высказываются по последовательно задаваемым вопросам) и предоставить специалистам раскрыть свой подход к освещению этой темы.
Юрий Корюкин сделал акцент на проблеме оценки эффективности проектов: “Некоторое время назад мы обратили внимание, что большинство наших заказчиков, даже тех, кто внедряет системы, совершенно не в состоянии ответить на вопросы об эффективности таких внедрений. Причем тут речь не только о системах потокового ввода (что касается нас напрямую), но также и о системах документооборота, об архивах и т. д.”. Логика дальнейших рассуждений такова: любой проект должен иметь четко обозначенную цель (чего очень часто нет), а раз так, то и какие-то изначальные критерии, позволяющие оценить, решена ли поставленная задача. В результате получается, что реализация проекта превращается из средства достижения цели в некую самоцель.
В качестве одного из ключевых показателей эффективности предлагается чисто финансовый показатель в виде оценки потери времени от “неработы” с документами (имеется в виду потеря времени из-за выполнения разного рода вспомогательных операций вроде банальной переноски документа из одного места в другое). По мнению представителя ABBYY, даже с помощью простого (“на пальцах”) расчета снижения трудозатрат с применением средств автоматизации можно убедить заказчика в реальной пользе такого проекта, а значит, и заинтересовать его руководство, что должно стать важным фактором успеха работы в целом.
Наталья Храмцовская сделала главный акцент на необходимость воли руководства предприятия внедрить СЭД. Без этого условия нельзя говорить о готовности компании к реализации проекта, в том числе в плане выделения ресурсов — финансовых, материальных, кадровых. Более того, участие топ-менеджеров в работе должно носить не разовый характер (подписал техзадание, отдал приказ), а постоянный, в том числе для оперативного преодоления возникающих трудностей.
Должна быть обеспечена правильная постановка задачи внедрения, сформулированы разумные достижимые цели, созданы условия для “вплетения” новой системы в существующие бизнес-процессы организации. Особое внимание следует уделить исполнению законодательно-нормативных требований, необходимо также наладить контроль за выдаваемыми в рамках проекта поручениями.
Другой ключевой аспект проблемы — люди, конечные пользователи. Нужно не только подготовить и обучить сотрудников, но и найти для них мотивацию. Надо помнить, что более квалифицированный персонал (который научится работать с компьютерными средствами) стоит дороже, поэтому руководству компании следует заранее готовиться к тому, что придется повышать зарплату своим подчиненным. И еще: процесс повышения квалификации и переподготовки сотрудников должен быть постоянным, что, в свою очередь, требует постоянного выделения средств на это.
Сергей Курьянов подошел к проблеме “неудачности” проектов с точки зрения оценки рисков при внедрении бизнес-решений. Что заказчик теряет в случае неудачи? Обычно компания считает, что ее затраты на внедрение равны расходам на приобретение лицензий и оплату услуг внешнего интегратора. А это, как правило, весьма значительная сумма, но дело в том, что на самом деле потери клиентов намного больше. Например, нужно учитывать затраты на оплату труда собственного персонала, в том числе и топ-менеджеров. Ведь все эти люди тратят на проект в ходе его внедрения немало времени, а время — это деньги. Обычно эту статью никто не считает, а она порой может серьезно превосходить расходы на внешние услуги.
Но кроме того, есть еще один серьезный риск. Его почти никто не принимает в расчет, хотя по своему весу он может превысить все остальные вместе взятые. Этот риск трудно посчитать количественно, но он очень велик. Речь идет о риске дискредитации идеи автоматизации на базе ИТ. “Если проект по внедрению СЭД будет провален, — подчеркнул Сергей Курьянов, — то вы в течение пяти последующих лет (это среднее время ротации персонала в компании) ни о каком внедрении ИТ даже заикнуться не сможете. Идея будет дискредитирована в глазах пользователей, без поддержки которых любой проект изначально обречен”. Риски же с точки зрения руководства компании заключается в том, что предприятие на этот срок лишится конкурентного преимущества, которое, может быть, сейчас и не очень нужно, но может понадобиться в любой момент.
Общий вывод из сказанного таков: руководство заказчика должно абсолютно четко представлять себе всю полноту рисков от неудачи проекта и, как следствие, изначально подойти к нему так, чтобы задуманная автоматизация была выполнена. И еще одно следствие: заказчик должен сделать так, чтобы исполнитель в максимальной степени разделил с ним все перечисленные выше риски, в том числе и в плане угрозы потери имиджа на рынке.
Идею оценки рисков продолжил Андрей Трещук. Он обратил внимание на недооценку заказчиком вопроса выбора базовой платформы для автоматизации. Проблема эта стоит сразу в нескольких плоскостях. Одна из них очевидна, но ее почти никто из заказчиков на практике не принимает во внимание: сможет ли выбранное решение удовлетворять растущие потребности клиента как в краткосрочной, так и в долгосрочной перспективе? Причем речь тут идет не только о масштабировании СЭД в плане наращивания рабочих мест, но и о реализации в ней новой функциональности, интеграции с другими подсистемами и т. д. Еще два момента не столь очевидны (особенно для бизнес-заказчиков), но на самом деле не менее важны: насколько выбранная платформа готова к обновлению ее версий и в какой степени вендор готов развивать свое ПО в будущем?
Надо заметить, что нормальной является и такая постановка вопроса: заказчик может выбрать для реализации проекта и довольно простое ИТ-решение, имея целью быстро справиться с текущими задачами и в будущем сменить платформу. Но в этом случае возможность такой модернизации нужно учитывать изначально, в ходе создания и эксплуатации системы. Впрочем, важность проблемы выбора технологической платформы не стоит преувеличивать. К сожалению, на практике часто получается так, что на “глюки” ПО списывается некомпетентность или нежелание как исполнителя, так и заказчика серьезно работать.
Наталья Егорова изложила свое четко структурированное представление о проектных проблемах. В качестве первого пункта она обозначила вопрос о готовности компании к реализации проекта, в том числе в плане выделения для этого требуемых ресурсов, быстрого принятия решений по ходу работы, необходимой коррекции бизнес-процессов и т. д. Не следует забывать и о том, что почти наверняка нужно будет проводить работы по реинжинирингу деловых процессов, так как автоматизация хаоса просто вредна. Типичной проблемой являются также несовпадение ожиданий заказчика и целей проекта, соответственно и полученного результата, а также недостаток людских ресурсов и со стороны заказчика, и со стороны подрядчика. Отдельно был выделен вопрос о неприятии проекта (точнее, неприятия изменений в своей работе в результате выполнения проекта) конечными пользователями. К сожалению, важность этой проблемы руководство компании часто просто не понимает, следствием чего, например, является его неготовность выделять время и средства на обучение своих сотрудников.
Значительную часть дискуссии заняло обсуждение того, что является критерием успешности проектов. Наталья Храмцовская предложила такой вариант: проект решил поставленные задачи, уложился во временные сроки и в отведенный бюджет, и при этом интерес высшего руководства к нему не потерян. Однако после интенсивного обмена мнениями эксперты согласились с формулировками, приведенными в отчете аналитической компании DSS Consulting: ·
под завершенным проектом подразумевается проект внедрения, работы над которым завершены, и компания-клиент может использовать его результаты. · под успешным внедрением специализированной системы понимается проект, в ходе которого были достигнуты цели проекта, и клиент готов дать рекомендации, положительно характеризующие продукт и проектную группу внедренца. И наконец, уже в самом конце обсуждения обозначился еще один вопрос: отличаются ли проекты по автоматизации документооборота от аналогичных внедрений других бизнес-решений, например ERP? Разумеется, подавляющее число всех перечисленных выше проблем (а в статье нашли отражение не все затронутые в ходе дискуссии темы) являются общими для ИТ-проектов в целом. Но одно отличие заметно: для СЭД проблема человеческого фактора со стороны заказчика существенно актуальнее, хотя бы потому, что такие проекты затрагивают интересы более широкого круга сотрудников, конечных пользователей.
Автор: Андрей Колесов
www.docflow.ru