Если провалился крупный проект по внедрению бизнес-приложения, это в большинстве случаев результат комбинации факторов, зависящих от нескольких сторон. Ниже мы обсудим пять наиболее часто муссирующихся причин провала ИТ-проектов.
1. Виновата компания-внедренец
Таково одно из первых обвинений, которые приходится слышать от пострадавшей компании. Большинство компаний не могут реализовать большие корпоративные ПО-проекты самостоятельно и исключительную роль в успехе проекта отводят интеграторам и внедренцам. Если как следует покопаться в причинах неудачи проектов, то выяснится, что вина очень часто действительно лежит на компании, осуществляющей внедрение. Тому имеется множество причин, начиная с технической некомпетентности и кончая некомпетентностью в бизнесе и в управлении проектом. Косвенное подтверждение - многочисленные юридические иски против внедренческих компаний. Например, осенью прошлого года в западной прессе появилась информация о большом судебном процессе. ИТ-консультантов обвиняют в том, что они практически разорили крупную фармацевтическую компанию. Проект по внедрению SAP, стоимостью 4,5 млн. долл. был сделан неудачно, внедренная ERP-система работала плохо, и компания потеряла всех реселлеров. Другой пример - удовлетворенный иск компании Evans Industries к J.D.Edvards, оказывавшей услуги по внедрению ERP-системы OneWorld.
Не поймите меня неправильно; большинство компаний, осуществляющих внедрение, - высококвалифицированные профессионалы. Но и тех немногих, которые бросают тень на всех, достаточно, чтобы испугать любую компанию.
2. Виноват разработчик ПО
Для того чтобы разделить вину поровну, придется рассмотреть роль человека, который, предлагая продукт для продажи, дает слишком много обещаний. Масса проектов проваливается просто потому, что продавцы обещают такое, чего программное обеспечение - и целая армия компетентных консультантов - никогда не смогут добиться. Однажды я принимал участие в "посмертном" обсуждении провалившегося проекта и обнаружил, что продавцы от четырех разных поставщиков, по большому счету, лгали заказчику, убеждая его в том, что обсуждаемые продукты могут действительно работать вместе. На совещании по поводу комментариев к заполненным ими RFP каждый продавец ручался за функциональную совместимость продуктов, и компания им поверила. Ирония судьбы - "посмертное" обсуждение проектов, на котором я присутствовал, было определенным образом "предсмертным" для незадачливой компании-заказчика, которая так и не смогла оправиться после провала, стоившего ей 50 млн. долларов. Вот такова цена лжи поставщиков ПО.
3. Административные вмешательства
Определенно бывают ситуации, когда заказчики могут винить только самих себя. Одна из наиболее распространенных причин для раскаяния - административные вмешательства высшего менеджмента компании в цели и задачи проекта. Обычно это происходит следующим образом: компания считает, что оставаться конкурентоспособной сможет только с помощью нового программного продукта. Она срочно выбирает какое-либо ПО и начинает проект внедрения. Три месяца работы над проектом - и в компании кто-то с большими политическими целями решает, что новое ПО не соответствует его потребностям. Команда, занятая проектом, прекращает работу и начинает серию совещаний по вопросу внесения новых, недавно возникших потребностей, в неплохо, в общем-то, выполненный вариант проекта. Проект уже дышит на ладан, но его добивают другие, политически зависимые от главного лица менеджеры, которые начинают влезать в проект со своими идеями и требованиями. Проект просто растаскивают на куски топ-менеджеры компании.
Довольно скоро проект, непомерно раздутый и совершенно вышедший из-под контроля (а собирался он просуществовать определенный срок и в рамках определенного бюджета), оказывается совершенно невыполнимым даже за вдвое большее время и впятеро большие деньги.
4. Вирус кастомизации систем и собственных разработок
Однажды я разговаривал с одним директором по информатизации, который с великой гордостью рассказал мне о том, как избавился от дорогостоящего поставщика ERP-системы и обошелся недорогой альтернативой, которая сэкономила ему несколько миллионов долларов. Когда мы обсуждали необходимую для него функциональность, стало очевидным, что этот недорогой продукт не имел готовой функциональности, которая требовалась его бизнесу. Нет проблем, сказал он, я могу добиться нужного результата, используя инструментарий поставщика и некоторые сторонние продукты.
Не имеет значения, что разработанные по заказу приложения могут поддерживаться только их разработчиками, а сторонние продукты могли быть взяты у начинающих фирм с неокрепшими финансовыми и проектными группами, никогда ранее не поддерживавшими заказчика такого ранга. Лишь немного подогнать под наши требования - и все будет хорошо, уверял меня директор по информатизации. Два года спустя незадачливый директор ушел, а "слишком дорогой" поставщик ERP вернулся и выглядел после всего этого довольно привлекательно с точки зрения стоимости.
5. Обучение пользователей
Это одна из моих любимых причин провала проектов, настолько распространенная и настолько нелепая, что против нее следует принять закон. Компания расходует миллионы долларов, тысячи часов и тонны политического капитала, реализуя новое корпоративное программное обеспечение, а затем решает дать своим пользователям один восьмичасовой обучающий курс.
Чтобы сделать ситуацию еще более нелепой, скажу: люди, которые любят учить так же, как все мы любим изжогу, проводят курс, используя материал, который может усыпить даже страдающего бессонницей. Бедные пользователи, и так встревоженные просочившимися слухами о грядущих крупных сокращениях, теперь уже убеждены, что все они кандидаты на увольнение, потому что никто из них не получил достаточной подготовки, чтобы быть компетентным. В результате новая система начинает работу, и… Далее сценарии разнятся, но итог один.
Главная причина - плохое управление проектами
Если вы посмотрите на корни причин, которые я назвал, то сможете сделать однозначный вывод: плохое управление является основной причиной почти каждого провала проекта. Возможно, что проблемы "плохого внедренца" не могут избежать даже хорошие менеджеры - многие консультанты, связанные с провалами крупных проектов, работают в фирмах, пользующихся хорошей репутацией. Но в большинстве упомянутых мною случаев имело место то, что называется неспособностью менеджмента понять, что входит в успешный корпоративный ПО-проект, и, грубо говоря, неспособностью действовать ответственно.
Справедливости ради нужно сказать: к тому времени, когда провал проекта становится публичным, поставщик ПО вынужден разделить вину плохого управления проектами. Потому что за любой неудачей стоит сотня потерянных для поставщика ПО возможностей исправить положение вещей. Помните о том, что программное обеспечение обычно работает достаточно хорошо. Это значит, что если поставщик ПО позволяет проблеме заходить так далеко, то процесс взаимоотношений с заказчиком сложился неудачно, чего никогда не должно было случиться при хорошем управлении проектом.
В следующий раз, услышав о провале проекта по внедрению корпоративной информационной системы, подумайте прежде всего о плохой работе менеджмента, а потом уже об отказе программного обеспечения. Плохое программное обеспечение не убивает компании, это делает плохой менеджмент.
