Внедрению систем планирования ресурсов предприятия (ERP) по-прежнему посвящается множество статей, в которых анализируются причины успеха и неудач такого рода проектов. Рассматриваемые в них вопросы в силу двух факторов должны заинтересовать всех директоров информационных служб. Во-первых, производители ERP-систем как никто другой активны в поисках новых возможностей, а во-вторых, те принципы заключения контрактов и управления, которые помогают определить результат крупных ERP-проектов, в той же мере применимы и к небольшим системам.
Действительно, крупные корпорации пользуются своими преимуществами при ведении переговоров и по завершении проекта выдвигают иски на крупные суммы, если внедрение завершилось неудачей. Компании среднего размера обладают значительно меньшими ресурсами. Серьезную ошибку в крупной компании трудно скрыть и трудно компенсировать. В более мелкой компании скрыть ошибку невозможно, а компенсировать ее еще сложнее.
Для детального изучения ERP-систем может потребоваться целый семестр и несколько лекций приглашенных специалистов. Если начать с обычного определения того, чего все же надо стараться избегать (невыполнения бюджета, срыва сроков, неадекватного функционирования или недостаточно высокой производительности — либо всего этого вместе), будет полезно рассмотреть следующие несколько моментов.
Своевременное выполнение
Тот факт, что производитель начинает работать над проектом до того, как подписан контракт, выглядит столь очевидной глупостью, что об этом не стоило бы вообще упоминать, если бы подобные ситуации не возникали постоянно. При отсутствии контракта у вас практически нет прав на интеллектуальную собственность, вам не гарантирован приемлемый уровень конфиденциальности, к тому же приходится платить по часам. Хуже всего то, что вы теряете инициативу в процессе подготовки контракта и ставите сами себя в сложное положение, если сделка в конце концов срывается.
Во время переговоров все считают, что если раньше начать работу над проектом, то можно сэкономить время на его реализацию. При этом, как правило, забывают, что время идет, сроки окончания ERP-проекта остаются неясными, и в результате вся выполненная до этого работа пойдет коту под хвост (поскольку у вас нет прав на ПО, вы не можете его использовать, поэтому не можете подписать приемлемый контракт), или же вы будете вынуждены согласиться на все, что вам предложит в конце этого процесса производитель ERP-системы. Учитывая, насколько часто столь простые соображения не принимаются во внимание, не стоит удивляться тому, что на карнавальный костюм «Супермена» наклеивают бирку с надписью «Не пытайтесь в этом костюме летать».
Цена и оплата
Цена — далеко не самый важный фактор в успехе проекта внедрения, и на самом деле вам не нужна куча денег. Старайтесь найти фиксированную цену и четко определить процесс внесения изменений в заказ. Не пытайтесь экономить каждый цент. Лучше сразу узнать реалистичную стоимость, чем пытаться отнять у производителя честно заработанную прибыль. Другими словами, рассчитывайте на то, что вас будут изводить всяческими изменениями заказа до тех пор, пока производитель не компенсирует снижение цен, которое вам удалось от него добиться.
Проверьте рекомендации, чтобы понять, как именно изменение заказа отразилось на других потребителях этого же производителя. Насколько возросла цена, на 10% или на 100%? Менялась ли она после изменения каждого пиксела на экране, или перерасчет проводился только в случае действительно крупных модификаций?
Что касается реально выплаченных сумм, то многие производители весьма болезненно реагируют на все денежные вопросы. Компенсационные выплаты — это замечательно (кстати, их еще предстоит добиться). Но если производитель — крупная компания, то эти выплаты на самом деле имеют меньший эффект, чем бы этого хотелось. Выплаты могут быть от 10 до 50%, и, как правило, их размер ограничен размером прибыли производителя. Если оплата работы выполняется по достижении ключевых этапов (и это предусматривает процедуру принятия продукта, а не просто его доставку), то к концу большого проекта компенсационные выплаты могут достичь довольно большой суммы. Чрезмерное стремление вернуть свои деньги может привести к тому же самому результату, что и противостояние крупному производителю, — к встречным искам.
Условия контракта
Наличие жесткого контракта, который допускает, что вы должны декларировать разрыв отношений и затем прекратить их, — вещь превосходная. Но, в конце концов, что вам нужнее: ERP-система или разбирательства по невыполненному контракту? Может быть, вам нужно, чтобы разрыв контракта оказался для производителя болезненным ударом, но вы сами от этого пострадаете не меньше его самого. Чаще всего вам требуется контракт, который предлагает обеим сторонам приемлемые для них условия, напрямую связанные с успехом. Ваш производитель заявит, что вам не нужен контракт, который заставляет все стороны держать наготове путь к отступлению, для чего достаточно строго следить за выполнением его условий. Это лишь часть правды. Вы и сами не хотите, чтобы стороны стремились лишь соблюсти каждую букву контракта. Вам необходим контракт, который позволил бы (если его правильно трактовать) обеим сторонам сотрудничать.
Взимайте реальную, конкретную денежную компенсацию за материальный ущерб (существенное невыполнение сроков, существенное отклонение от условий) и подумайте о возможности предложить дополнительные вознаграждения или бонус за те нарушения выбранных параметров, которые выгодны обеим сторонам. Добавьте ясные процедуры расширения, позволяющие эффективно разрешить каждый спорный момент. Требуйте, чтобы от каждой из сторон над проектом работал постоянный персонал, и предоставьте каждой из сторон право (и верное средство) убедить другую сторону, что ведущий специалист выбрал путь, который должен привести к успеху.
Принятие и тестирование
Промежуточное принятие продукта должно быть условным, а не абсолютным. И условие это состоит в том, что в конечном итоге будет работать вся система в целом. Зачем принимать красивые экраны, за которыми не стоит корректно работающее ПО? В контракте должны быть четко определены процедуры принятия и непринятия продукта, а также процедура переделки некачественно выполненного задания.
Более того, вам необходимо обговорить право проверять то, что делает ваш производитель. В свою очередь, вашему производителю необходимо предоставить право проверять вашу работу. Наконец, обеим сторонам нужно иметь право найти третью сторону, которая поможет определить, выполняются ли объективные стандарты. Ни одна из сторон не должна единолично решать, насколько хорошо она выполнила свою работу. При выборе третьей стороны убедитесь, что она действительно независимая, что это не производитель, для которого основным стимулом может стать возможность самому получить этот заказ.
Ответный удар
Иногда приходится поступиться некоторыми принципами. Так, директору информационной службы не составит труда заявить, что самое лучшее внедрение включает в себя минимум унаследованных интерфейсов и предусматривает минимальную настройку — каждый должен или довольствоваться готовым решением ERP, или показать, что система не соответствует ERP. Но несмотря на все беды унаследованных систем, иногда нам приходится с ними смириться. В некоторых случаях существующий бизнес-процесс не только уникален, но и дает преимущества перед конкурентами, в других случаях его модификация в соответствии с новой ERP-системой обойдется слишком дорого. В этих ситуациях лучше проконсультироваться у специалистов. Такая модификация может отразиться на операциях компании, ее бюджете и даже иметь политические последствия.
Не забывайте также, что внедрение ERP коснется всех долговременных и созданных тяжким трудом преимуществ и свойств, составляющих уникальную атмосферу вашей компании. До начала проекта убедитесь, что руководители подразделений понимают, что система планирования корпоративных ресурсов — это не только польза, но и потери: некоторые из существующих процессов придется изменить с целью их упрощения и для достижения их согласованности с другими процессами организации.
Существуют, конечно, и другие вопросы — каждый успех и каждая неудача дают свои уроки. Но если вы представите, как эти идеи можно применить к вашей организации, это будет неплохим началом.
Уэйн Д. Беннет — руководитель отдела Commercial Technology Practice Area компании Bingham Dana