Любые упоминания программных продуктов в статье не означают претензий к их функциональности. Равно как и упоминания компаний не означают критики их действий. Я уверен, что провалы проектов внедрения ERP-систем, о которых пойдет речь, связаны исключительно с ошибками менеджмента, причем руководители и сотрудники компаний, допустившие эти ошибки, скорее всего там уже не работают.
Суть проекта
Target — американская торговая сеть, крупнейший после Wal-Mart дискаунтер в США: 350 тыс. сотрудников, около 1,8 тыс. магазинов. В январе 2011 года компания анонсировала свой выход на канадский рынок, где к 2014-му планировала открыть не менее ста торговых точек. Но в январе 2015-го объявила о прекращении всех операций в Канаде, о закрытии всех 133 магазинов и об увольнении более 17,5 тыс. работников. Target Canada инициировала процедуру собственного банкротства. К апрелю все магазины Target в Канаде были закрыты; затраты на продвижение этого бизнеса составили 7 млрд долл.
В Target Canada внедрялась система SAP R/3, в качестве консультанта по внедрению выступила компания Accenture. Проект замечателен тем, что как заказчик, так и подрядчик сделали максимум возможных ошибок, в том числе очень грубых. Ошибки были самые разные — в найме и мотивации персонала, в архитектуре системы, в планировании подсистемы управления цепочками поставок, в управлении данными, во взаимоотношениях заказчика и консультанта по проекту.
Хаос в данных
Три года во внедряемом решении фактически отсутствовала подсистема верификации данных. Данные вводил кто попало и как попало. Программное обеспечение верификации было запущено только в 2014-м, когда система была переполнена ошибочными данными и количество ошибок перешло в неприемлемое качество функционала решения. В любом случае никакая программа верификации не способна идентифицировать содержательные ошибки, она может только проверить формат вводимых данных и (иногда) допустимость значений. Точность вводимых данных программа верификации обеспечить не может. Но практиковать двойной ввод для абсолютно всех данных в наше время — это нонсенс.
Для меня как специалиста в области систем электронного документооборота очевидно, что естественную верификацию данных может обеспечить только СЭД, работающая в тесной интеграции с ERP-системой. Только в СЭД все данные готовятся ответственными сотрудниками, работающими на местах возникновения документов, и являются составной частью этих документов (контрактов, инвойсов, ордеров и т. п.), а сами электронные документы при этом проходят неоднократную проверку в процессе согласования между различными службами.
У каждой ошибки при таком подходе всегда есть автор, и пропустившие ошибку контролеры — все сотрудники, имеющие отношение к подготовке материалов, — явно указаны в карточках первичных документов СЭД. А Target Canada нанимала персонал для ввода данных в Индии (видимо, это было дешевле), а затем данные передавались в Канаду для ввода в систему. Ну а в Канаде задачу аврального ввода данных о 75 тыс. товаров передали вчерашним школьникам, которых наняли на должность мерчандайзеров. Разумеется, это были никакие не данные. Это был мусор.
Никогда не запускайте проект внедрения ERP-системы, если у вас нет системы сбора достоверных первичных данных. В зависимости от специфики бизнеса это может быть СЭД, online-система приема заказов, межведомственная система электронного обмена документами, устоявшиеся корпоративные системы ваших партнеров.
Персонал и корпоративная культура
Удивительно, что в Target Canada среди 17 тыс. сотрудников не нашлось никого, кто обладал бы профессиональными навыками управления проектами, — но это факт. Менеджеры-экспаты из США привыкли работать в стабильной организации и понятия не имели, как надо реализовывать новые проекты.
В США Target позиционирует себя как компания с приоритетом корпоративной культуры, при найме сотрудников отдающая предпочтение тем, кто готов поддержать девиз «Fast, fun and friendly» и соответствует корпоративному духу. Опыт и квалификация при этом вторичны — новый сотрудник на первых порах работает в паре с ментором. Такой подход отлично показывает себя в корпорации с устоявшимися бизнес-процессами, но для экспансии на новый рынок, осложненной внедрением новой информационной ссистемой, он дал сбой. Тони Фишер, назначенный президентом Target Canada, категорически не был способен управлять новым проектом. Принцип «hiring for culture over experience» не годится там, где нужны специалисты, готовые принимать на себя индивидуальную ответственность за правильные решения.
Крылатое выражение «хороший человек — это не профессия» как нельзя более применимо к менеджерам из сферы высоких технологий. Определить профпригодность в этой сфере действительно трудно, и это часто делают субъективно, оценивая, нравится ли претендент как человек первому лицу предприятия и как много мест он сменил в должности ИТ-директора. Но так оценивать ИТ-сотрудников — ошибка, поскольку в этой сфере настоящие специалисты редко соответствуют критерию «хорошего парня», предпочитают вести себя независимо и вовсе не стараются понравиться начальнику, зная, что найти работу для них не проблема. Так что оценивать их надо по двум основным критериям: профессиональный уровень и ответственность.
Сами запланировали свой День Икс
К моменту запуска в Target Canada не работало практически ничего. В подсистеме управления поставками не функционировало ни автоматическое определение остатков, ни расчет количества товаров для пополнения, ни логистика, ни оптимизация складских запасов, ни уведомление поставщиков. Поставщиков нагрузили необходимостью обеспечивать множество дополнительных реквизитов на поставляемые товары — на каждую единицу товара десятки реквизитов. Естественно, дополнительные данные либо вовсе не предоставлялись, либо предоставлялись с ошибками. Из-за того, что система не работала, ее отключили, и пополнение товарами центров дистрибуции делалось вручную. В результате центры оказались переполнены, образовывались очереди из фур, которые некуда было разгружать.
Но ведь запуск корпоративной ИТ-системы — совсем не то же самое, что запуск экспериментальной космической ракеты, когда весь проект нацелен на то, чтобы в День Икс выяснить, полетит она или не полетит.
Если возможно, запускайте систему частями, чтобы минимизировать ущерб и постепенно ликвидировать возникающие ошибки. Чтобы не дать возникнуть цунами из ошибок, когда останавливается вся система целиком и нет путей к исправлению ситуации.
Поставщика надо контролировать
После провала проекта компания Accenture официально заявила, что внедрение SAP R/3 в Target Canada ею завершено, что имеется независимое заключение о его успешности и что она не имеет отношения ни к каким проблемам данного проекта.
Такая, мягко выражаясь, независимая позиция подрядчика стала возможной потому, что заказчик должным образом не закрепил в контракте его ответственность за результаты работы по проекту. Так бывает очень часто, но именно заказчик обязан обеспечить разумную юридическую ответственность подрядчика. В противном случае в проект изначально закладываются риски неисполнения.
Принцип «У нас достаточно денег, и мы можем позволить себе запуск проекта под ключ» никогда не работает для больших проектов. Если заказчик пускает дело на самотек и верит всему, что ему говорит поставщик решения, его ждет провал. Как только подрядчик начинает понимать, что у заказчика нет компетенции в проектном управлении, реализация проекта тут же деградирует и съезжает на самый легкий и накатанный путь. До 80% средств он потратит на создание толстых пачек документации, которые будут преподнесены как результат важного самостоятельного этапа проекта, но по сути нужны они не заказчику, а подрядчику — как рабочая документация для настройки системы. Это формализованные документы, описывающие структуры данных и бизнес-процессы на языке ИТ, оценка таких документов доступна лишь специалистам в области разработки корпоративных информационных технологий, которых на предприятии заказчика может и не быть. Самостоятельной ценности они не имеют, заказчику нужна работающая система, а не кипа бумаг. Но поскольку разработка этой документации занимает существенную часть времени и бюджета проекта, заказчик вынужден принять и оплатить эту работу.
Нанимайте в проект стороннего куратора или компанию-консультанта для защиты ваших интересов. Куратор будет играть на вашей стороне и разговаривать с подрядчиком на профессиональном языке. Принципиально, чтобы кураторы оставались независимыми, поэтому брать их в штат не рекомендую.
Хуже того, на этапе настройки системы часто выясняется, что описания бизнес-процессов и структур данных в отдельных документах существуют независимо от реальных бизнес-процессов. И тем не менее, раз уж всё утверждено и подписано, заказчик вынужден продлить сроки проекта и выделить дополнительные финансы.
Ко всем сдаваемым документам нужно требовать работающие прототипы программного обеспечения, реализованные на той платформе, которая предусмотрена проектом. Наличие такого прототипа, демонстрирующего результаты разработки документа, сразу покажет его ценность или бесполезность. В идеале разработка проектной документации с начала проекта и до конца должна вестись параллельно с настройкой реальной системы. Затраты на неизбежные при таком подходе изменения в структурах реальных данных и в функциональности будут несравнимы с затратами на исправление множества ошибок в давно принятых, оплаченных и наполовину забытых документах, которые никто толком не анализировал при приемке. Потому что, как известно, наилучшим критерием истины является практика, т. е. реально работающая в соответствии с созданными документами система, а вовсе не мнение сотрудника компании-заказчика, который некогда завизировал приемку документов по проекту и давно уже уволился.
Известные риски при внедрении ERP-проектов
К основным рискам проектов внедрения ERP-систем я бы отнес следующие.
- Превышение стоимости проекта и затягивание сроков его реализации. К сожалению, такие риски реализуются почти всегда. Задача состоит в том, чтобы их минимизировать, а это потребует детального разграничения ответственности между заказчиком и подрядчиком за совместные работы по проекту и строгого контроля сроков исполнения работ.
- Недостаточная квалификация членов команды проекта со стороны подрядчика. Подобные риски возникают и при замене членов этой команды. Текучка кадров приводит к затягиванию сроков реализации и к снижению качества проекта в целом.
- Весьма существенные риски в проект привносит проблема «плохих данных», которую мы подробно обсуждаем в статье. Эта проблема может серьезно повлиять на результат внедрения.
- Несоответствие затрат на проект и полученных результатов. Это тот самый случай, когда выясняется, что «овчинка выделки не стоит». Вроде что-то и работает, но понесенные затраты и расходы на техническую поддержку превращают приобретенную систему в «чемодан без ручки», когда и отказаться от системы нельзя, и платить за эксплуатацию не очень хочется из-за ее очевидной неэффективности.
Ко всему, что связано с реализацией проекта ERP, подходите в первую очередь с точки зрения минимизации своих рисков. Начинайте с анализа договоров с подрядчиком. С этой точки зрения оценивайте всю ответственность — и вашу, и подрядчика, а также риски превышения стоимости и сроков работ. Старайтесь отказываться от условий договора, в которых закладываются затраты без очевидных результатов. Минимизируйте и нормируйте консультации с повременной оплатой без очевидного зафиксированного результата. Практикуйте гарантийные требования к подрядчику не только на постпроектный период, но и в течение срока реализации проекта, на промежуточные результаты. Большая часть рисков по проекту закладывается в условиях договоров, которые заказчики заключают с подрядчиками, поэтому, готовясь подписать такой договор, спросите себя, позволяет ли он подрядчику получить деньги, не отвечая за реальный запуск системы в эксплуатацию. Правильно составленный, сбалансированный по обязательствам договор стимулирует работу на результат и направлен на достижение успеха проекта.
Выбор системы
Самое забавное в истории с проектом Target в Канаде таково: у заказчика было давно и успешно работающее в США решение, от которого в Канаде отказались по неубедительным причинам. Ведь Target — одна из крупнейших в стране розничных сетей. Но корпоративная информационная система, многие годы успешно обслуживавшая все бизнес-процессы Target в США, не была выбрана для поддержки экспансии в Канаду по странным основаниям — якобы она не поддерживала операции в канадских долларах и не позволяла обрабатывать тексты с французскими буквами, отличающимися от английских. Поэтому для запуска бизнеса в Канаде выбрали SAP R/3. Вопрос, насколько правильно в силу этих чисто технических причин, которые можно было бы быстро разрешить, отказываться от работающей технологии и принимать решение о запуске новой системы, остается открытым.
Target, конечно, не первая и не последняя в списке провалов при внедрении ERP. Однако эта компания все-таки смогла всех удивить, во-первых, огромной суммой убытков и, во-вторых, отказом от работающего, отлаженного решения. Назначенные топ-менеджеры Target Canada никогда в жизни не сталкивались с реализацией масштабных проектов по внедрению новых технологий — они работали в США на отлаженном решении и не представляли себе реальных трудностей при внедрении новой корпоративной системы.
Если у вас есть работающая, отлаженная технология, не стоит ее менять — до тех пор, пока ее недостатки не перекроют ее достоинства. Особенно если у вас нет полной уверенности в том, что новая технология лучше. И если процесс внедрения новой технологии является весьма затратным и несет в себе риски.
ИТ-проект усугубил нерешенные проблемы бизнеса
Огромную сумму убытков Target нельзя объяснить только провалом ИТ-проекта. Для меня очевидно, что у Target Canada были большие проблемы с маркетингом. Экспансия из США на новый рынок в Канаде не была хорошо продумана. Появилась возможность арендовать большое количество торговых площадей, принадлежавших торговой сети Zellers, и поспешное решение было принято, чтобы опередить конкурента — Wal-Mart. Но магазины эти были убыточными, сеть Zellers закрылась, а Target пришлось еще платить ей и за аренду. В магазинах Target было мало покупателей. Думаю, если бы при всех провалах в ИТ у Target была положительная динамика продаж, они всё же не закрылись бы— но такая динамика была лишь у нескольких магазинов из 133.
Уверен, что маркетинговое решение проблемы существовало, и не одно: адаптировать ассортимент к канадскому рынку, продавать популярные товары с большой скидкой, найти и продавать что-то нужное, чего нет в Wal-Mart, делать подарки, завести игровые зоны для детей. Но таких попыток предпринято не было.
ИТ-проект не решит проблемы бизнеса, связанные с маркетингом (если, конечно, он не направлен напрямую на решение проблем маркетинга, на расширение рынка, например, на онлайн-торговлю). Но он вполне может усугубить существующие проблемы. Поэтому не стоит одновременно пытаться решить две серьезные проблемы — выход на новый рынок и запуск новой неотлаженной ИТ-системы. Лучше решать проблемы по мере их поступления.
Заключительный позитив
По статистике лишь около 50% ИТ-проектов заканчиваются успешным внедрением. И это хорошо, поскольку проекты, которые в полном соответствии с ГОСТ тридцатилетной давности ведутся в основном ради генерации проектной документации по ним, по идее вообще не должны приводить к успеху. Если же не составлять план проекта так, что больше половины времени уходит на изготовление бумаг, если настройку программных продуктов, используемых в проекте, начинать одновременно с разработкой документации и поэтапно предъявлять заказчику промежуточные результаты, то старания и упорство заказчика и подрядчика будут приводить к успеху гораздо чаще.
Несколько ссылок
Таких историй опубликованы сотни, а еще тысячи не выносят сор из избы и молчат, списывая убытки от ERP-проектов. При этом у подрядчиков «все документы в порядке», и вину за неуспех проекта они возлагают исключительно на заказчика, который потратил миллионы долларов и остался ни с чем. В некоторых случаях выясняется, что по договору подрядчик брал на себя ответственность только за разработку документов, а что касается запуска системы в эксплуатацию, то здесь вся ответственность возлагалась на заказчика.
Billion-Dollar Flop: Air Force Stumbles on Software Plan
Многолетний проект автоматизации ВВС США с использованием ERP Oracle закончился провалом с потерей миллиарда долларов. Расследованием данного случая занимался комитет по вооруженным силам Сената США.
DHL потеряла 345 млн евро из-за провального ИТ-проекта SAP
В начале декабря 2015 года SAP заявила о своей непричастности к провальному ИТ-проекту в Deutsche Post DHL, из-за которого немецкая компания не досчиталась 0,345 млрд евро доходов.
California sues SAP over failed payroll software project
Потратив три года и 50 млн долл., компания SAP так и не смогла внедрить систему расчета заработной платы даже для пилотной группы из 1,5 тыс. сотрудников.
Округ Марин против Deloitte: мошенничество с проектом внедрения SAP
Представители округа Марин были вынуждены прибегнуть к последней мере воздействия на Deloitte Consulting, обвинив компанию в мошенничестве с внедрением решения SAP ERP, которое спустя четыре года после внедрения все еще не работает. В своем заявлении представители округа требуют возмещения ущерба в 30 млн долл., а также просят наказать компанию штрафом.
Oracle, Montclair State University settle lawsuit over PeopleSoft software project
Провал проекта Oracle для государственного университета Монтклера привел к судебной тяжбе с требованием возместить многомиллионные убытки.
