Меню

Как избежать мошенничества в области ERP консалтинга

Сотрудник компании Panorama Consulting Эрик Кимберлинг делится своим взглядом на ситуацию, сложившуюся на рынке западного ERP консалтинга, и советует обратить внимание на три момента, которые должны уменьшить количество нечистоплотных отношений на проектах.

Предисловие

Сотрудник компании Panorama Consulting Эрик Кимберлинг делится своим взглядом на ситуацию, сложившуюся на рынке западного ERP консалтинга, и советует обратить внимание на три момента, которые должны уменьшить количество нечистоплотных отношений на проектах.

Юрий Нечитайлов
Главный редактор SAP Professional Journal Россия

Авторство: Эрик Кимберлинг (Panorama Consulting), 9 мая2012

Любой, кто смотрел хотя бы одну серию телесериала «Дом лжи», представляет себе возмутительную (хотя время от времени и увлекательную) картину индустрии консалтинга. В одной из серий якобы рассматривается понятие теневого ERP консалтинга, которое представляет большой интерес для нашей компании Panorama, так как мы являемся консалтинговой фирмой в сфере ERP. Пусть это может показаться натянутым, а шоу стремится сильно шокировать аудиторию, в нем действительно делается акцент на потенциальные риски, возникающие из-за использования сомнительных с этической точки зрения приемов при найме консультантов, которые должны помочь вам реализовать свои ERP инициативы.
    Кроме того, я потратил время на изучение мошеннической практики в данной индустрии, в основном, в контексте показаний свидетелей-экспертов в громких делах о банкротстве, а также судебных разбирательств. В подобных случаях нашей фирмой нанимаются адвокаты, которые выполняют объективную и независимую оценку ситуации: что удалось, а что пошло не так в рассматриваемом процессе внедрения ERP; и, к сожалению, мы часто обнаруживаем, что причина неудач коренится в теневом консалтинге. Может, это не всегда приводит к откровенному обману или искажению фактов, однако часто налицо признаки того, что консалтинговая фирма или компания, занимающаяся системной интеграцией, не учитывала насущные интересы клиента. К примеру, фирмы, занимающиеся системной интеграцией и традиционные ERP консультанты печально известны тем, что торгуют продукцией, которая обеспечивает им наиболее прибыльные откаты, или же решениями, которые не совсем подходят клиенту, но зато каким-то образом помогают набить им собственные карманы.
    Примером подобного мошенничества являются получившие широкую огласку обвинения в мошенничестве против фирмы, занимающейся системной интеграцией ERP, поступившие от города Нью-Йорк. И хотя город не является клиентом компании Panorama, и мы не предоставляем им экспертные заключения или иные консалтинговые услуги, тем не менее очевидно, что мошенничество представляет реальную опасность в данной индустрии. Кроме того, можно найти и другие примеры, включая консультантов, которые стремятся проводить телефонные переговоры от имени младших и менее квалифицированных консультантов для того, чтобы выиграть в деловом отношении, завышая цены, а также получая откаты за рекомендации, предоставленные своим клиентам. И хотя такое поведение не является нормой, но определенно хватает реальных примеров, чтобы любому ИТ- или финансовому директору стало дурно.
    У большинства организаций не хватает внутренних ресурсов, способности или методологии, чтобы эффективно управлять своим собственным программным обеспечением ERP, и в связи с этим они нуждаются в работоспособных и порядочных консультантах, которые обеспечили бы успешное функционирование ERP системы. Так что же

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев12

Комментарий от  

Михаил Хорпяков

  |  09 октября 2012, 09:37

Что-то мне кажется, распознать "мошенничество" в SAP достаточно просто. Смысл статьи: следите, как работает подрядчик. Вопрос в том, есть ли в этом потребность у заказчиков...

Комментарий от  

Юрий Нечитайлов

  |  09 октября 2012, 17:31

Что-то мне кажется, распознать "мошенничество" в SAP достаточно просто. Смысл статьи: следите, как работает подрядчик. Вопрос в том, есть ли в этом потребность у заказчиков...

Михаил, спасибо за отклик!
Возможно, в переводе не удалось достаточно точно расставить акценты. Пожалуй, стоит чуть поменять название с "Как распознать мошенничество..." на "Как избежать мошенничества...". Речь, конечно, идет о том как заказчику, который, возможно, впервые в жизни столкнулся с ERP избежать того, что подрядчик станет работать по принципу "и так сойдет", давя при этом смесью своего опыта и авторитета, и уверяя, что "все так и должно быть". Распознать "мошенничество" просто только тому, кто детально представляет механизм этого "мошенничества". Но лучше его просто попытаться избежать. За фокусником можно пристально следить, при этом толку может быть не очень много. Важно еще понимать за какой рукой и в какой момент следить. Может поделитесь своим опытом? На что именно следует обращать внимание заказчику? Хотя бы пару пунктов?
 
Или я вас неправильно понял, и вы считаете, что заказчику в большинстве случаев нет дела до того как протекает внедрение, а потому об этом и говорить нечего?

Комментарий от  

Михаил Хорпяков

  |  10 октября 2012, 09:14

Михаил, спасибо за отклик!
Возможно, в переводе не удалось достаточно точно расставить акценты. Пожалуй, стоит чуть поменять название с "Как распознать мошенничество..." на "Как избежать мошенничества...". Речь, конечно, идет о том как заказчику, который, возможно, впервые в жизни столкнулся с ERP избежать того, что подрядчик станет работать по принципу "и так сойдет", давя при этом смесью своего опыта и авторитета, и уверяя, что "все так и должно быть". Распознать "мошенничество" просто только тому, кто детально представляет механизм этого "мошенничества". Но лучше его просто попытаться избежать. За фокусником можно пристально следить, при этом толку может быть не очень много. Важно еще понимать за какой рукой и в какой момент следить. Может поделитесь своим опытом? На что именно следует обращать внимание заказчику? Хотя бы пару пунктов?
 
Или я вас неправильно понял, и вы считаете, что заказчику в большинстве случаев нет дела до того как протекает внедрение, а потому об этом и говорить нечего?

Я уверен, что если со стороны заказчика есть заинтересованность в получении именно практического, полезного результата, то и подрядчик будет выбран нормальный, и мошенничеству нет шансов случиться. В этом плане внедрение SAP от любого другого подряда не отличается. В статье предлагается нанимать третью сторону (недвусмысленно намекая на Панораму) для обеспечения контроля за методиками, сроками выполнения проекта и вывешивания противовеса. Проблема в том, что конечный заинтересант всё-равно остаётся один - увеличивается только "обзорность" проекта.

Комментарий от  

Олег Чирва

  |  10 октября 2012, 12:36

Я уверен, что если со стороны заказчика есть заинтересованность в получении именно практического, полезного результата, то и подрядчик будет выбран нормальный, и мошенничеству нет шансов случиться. В этом плане внедрение SAP от любого другого подряда не отличается. В статье предлагается нанимать третью сторону (недвусмысленно намекая на Панораму) для обеспечения контроля за методиками, сроками выполнения проекта и вывешивания противовеса. Проблема в том, что конечный заинтересант всё-равно остаётся один - увеличивается только "обзорность" проекта.

А ведь участие третье стороны в больших проектах это достаточно распространенная практика, но увы, пока она чаще использовалась в строительных контрактах, а к внедрениям ERP только-только приближается! В FIDIC'овских контрактах, например, очень не плохо формализована роль этой третьей стороны - роль названа Инженер - не является представителем заказчика в том смысле, что должен принимать во внимание только его интересы. Обычно инженер действует в качестве беспристрастного посредника между заказчиком и подрядчиком. Инженер в международной практике строительства - технический эксперт, в функции которого входит разрешение споров в процессе выполнения работ, выдача свидетельств об удовлетворительном завершении определенных стадий работ или всех работ, распоряжений в отношении устранения недостатков в работе.
 
Вот и получается, что Заказчик на строительных контрактах не боится признать свою не достаточную осведомленность в специфике работ Исполнителя, а при внедрении Информационных систем рискует и полагается на добропорядочность Исполнителя.
 
Хотя, я непосредственно руководил проектом, где Заказчик таки воспользовался услугами эксперта, но скорее не для контроля за проектом, а для осуществления независимой оценки корректности принимаемых концептуальных решений!

Комментарий от  

Михаил Хорпяков

  |  10 октября 2012, 13:47

А ведь участие третье стороны в больших проектах это достаточно распространенная практика, но увы, пока она чаще использовалась в строительных контрактах, а к внедрениям ERP только-только приближается! В FIDIC'овских контрактах, например, очень не плохо формализована роль этой третьей стороны - роль названа Инженер - не является представителем заказчика в том смысле, что должен принимать во внимание только его интересы. Обычно инженер действует в качестве беспристрастного посредника между заказчиком и подрядчиком. Инженер в международной практике строительства - технический эксперт, в функции которого входит разрешение споров в процессе выполнения работ, выдача свидетельств об удовлетворительном завершении определенных стадий работ или всех работ, распоряжений в отношении устранения недостатков в работе.
 
Вот и получается, что Заказчик на строительных контрактах не боится признать свою не достаточную осведомленность в специфике работ Исполнителя, а при внедрении Информационных систем рискует и полагается на добропорядочность Исполнителя.
 
Хотя, я непосредственно руководил проектом, где Заказчик таки воспользовался услугами эксперта, но скорее не для контроля за проектом, а для осуществления независимой оценки корректности принимаемых концептуальных решений!

Если здание упадёт, шуму будет гораздо больше чем от криво внедрённой ERP. Хочу ещё провести параллель из мира разработки ПО. В этой области всегда разделяют роль тестера и разработчика. Совмещать эти обязанности нельзя, так как имеется прямой конфликт интересов: разработчик должен сдать функционал в срок, тестер же - найти максимальное количество ошибок, тем самым отодвигая сдачу. Роль тестера при внедрении ERP не всегда может выполнить заказчик, прежде всего ввиду недостатка квалификации. Для этого логично привлечь третью сторону.

Комментарий от  

Юрий Нечитайлов

  |  11 октября 2012, 01:22

Я уверен, что если со стороны заказчика есть заинтересованность в получении именно практического, полезного результата, то и подрядчик будет выбран нормальный, и мошенничеству нет шансов случиться. В этом плане внедрение SAP от любого другого подряда не отличается. В статье предлагается нанимать третью сторону (недвусмысленно намекая на Панораму) для обеспечения контроля за методиками, сроками выполнения проекта и вывешивания противовеса. Проблема в том, что конечный заинтересант всё-равно остаётся один - увеличивается только "обзорность" проекта.

Михаил,
Конечно, согласен с вами относительно самопродвижения Панорамы.
Еще раз подчеркну, что термин "мошенничество" следует, скорее, понимать как смесь природной лени и некоторой некомпетентности. Может термин "халтура" в нашем культурном контексте был бы уместнее.
Поскольку, с одной стороны, система чрезвычайно сложная, внедрение требует не только ее понимания, но и знание бизнеса заказчика, знание передового опыта внедрения в данной сфере/отрасли, и, в то же время, многие консультанты пашут на износ, переходя с проекта на проект, и почти не занимаясь ни обучением, ни самообучением, в силу этого риск столкнуться с подобной ситуацией, на мой взгляд, очень и очень велик.
 
Позволю от себя добавить пару пунктов, которые также могли бы рассматриваться в качестве дополнительных индикаторов подобного рода риска:
 
(1) Чтение профессиональных журналов и книг (в том числе на английском языке).
Как ни странно, все еще довольно распространена ситуация, когда консультанты предпочитают пользоваться свободными источниками информации, такими как форумы и SDN, жертвуя вниманием профессиональным книгам и журналам. В результате вместо изучения проверенных, системно изложенных знаний, и самых актуальных вопросов, основанных на передовом опыте лидеров рынка, консультанты, зачастую, занимаются поиском ответов на технические вопросы, сформулированные ими же самими, даже и не представляя, что существуют более оптимальные и простые решения. Форумы и SDN тоже нужны, но если консультант не читает книги и журналы - это верный знак, что он непрофессионально относится к своей работе. "Ремесленники", идущие из года в год по накатанной дороге, и не обращающие внимания на то, что творится вокруг, в условиях столь быстро развивающейся системы резко повышают вероятность возникновения подобных рисков.
 
(2) Участие в открытых дискуссиях на профессиональных площадках, написание книг/статей, ведение блогов.
Если консультант не боится делиться ноу-хау, значит он не топчется на месте, а учится и растет вместе с изменяющейся и развивающейся системой. Если консультант считает, что раскрывая секреты, он в конце концов будет способствовать взращиванию кадров, которые его смогут заменить, - то либо он ооочень ограничен в своих знаниях и не растет, либо он не там "пасется", если его, супер-гуру, смогут заменить учеником, который познал лишь крохотную часть айсберга и не способен к самостоятельному воспроизводству подобных ноу-хау.

Комментарий от  

Юрий Нечитайлов

  |  11 октября 2012, 21:50

А ведь участие третье стороны в больших проектах это достаточно распространенная практика, но увы, пока она чаще использовалась в строительных контрактах, а к внедрениям ERP только-только приближается! В FIDIC'овских контрактах, например, очень не плохо формализована роль этой третьей стороны - роль названа Инженер - не является представителем заказчика в том смысле, что должен принимать во внимание только его интересы. Обычно инженер действует в качестве беспристрастного посредника между заказчиком и подрядчиком. Инженер в международной практике строительства - технический эксперт, в функции которого входит разрешение споров в процессе выполнения работ, выдача свидетельств об удовлетворительном завершении определенных стадий работ или всех работ, распоряжений в отношении устранения недостатков в работе.
 
Вот и получается, что Заказчик на строительных контрактах не боится признать свою не достаточную осведомленность в специфике работ Исполнителя, а при внедрении Информационных систем рискует и полагается на добропорядочность Исполнителя.
 
Хотя, я непосредственно руководил проектом, где Заказчик таки воспользовался услугами эксперта, но скорее не для контроля за проектом, а для осуществления независимой оценки корректности принимаемых концептуальных решений!

Олег, спасибо за интересный пример!
 
Вероятно, на строительных контрактах заказчик не стесняется признать свою недостаточную осведомленность в силу того, что у него нет ни одного человека, который бы разбирался в строительстве. При внедрении же ERP, у заказчика есть ИТ-отдел, который может посчитать себя весьма причастным, и достаточно компетентным для надзора над проектом. Хотя внедрение ERP касается ИТ-отдела лишь отчасти, и почти ни один такой отдел не обладает достаточными представлениями ни об ERP, ни о ее внедрении (иначе они сами бы ее и внедряли). Поэтому хотелось бы поконкретнее сформулировать риски (так, чтобы они действительно "цепляли") и предложить пути решения.
 
Достаточно ли уменьшается риск приглашением третьей стороны? Каким требованиям должна удовлетворять эта "третья сторона", чтобы риски все же уменьшились?
 
Мне казалось, что в случае SAP "есть такая партия" - сервисы в рамках услуги SAP Enterprise Support. Вы так не считаете?

Комментарий от  

Юрий Нечитайлов

  |  11 октября 2012, 21:53

Если здание упадёт, шуму будет гораздо больше чем от криво внедрённой ERP. Хочу ещё провести параллель из мира разработки ПО. В этой области всегда разделяют роль тестера и разработчика. Совмещать эти обязанности нельзя, так как имеется прямой конфликт интересов: разработчик должен сдать функционал в срок, тестер же - найти максимальное количество ошибок, тем самым отодвигая сдачу. Роль тестера при внедрении ERP не всегда может выполнить заказчик, прежде всего ввиду недостатка квалификации. Для этого логично привлечь третью сторону.

Михаил,
 
Спасибо, что вспомнили про Тестера в качестве "третьей" стороны.
Вы хотите сказать, что тестирование не имеет регламента?
Если Тестер способен находить ошибку за ошибкой, то флаг ему в руки!
Задача же Разработчика не только в том, чтобы сдать "в срок", но и в том, что сданное должно соответствовать заявленным характеристикам.
А здесь уже нужно вести речь о грамотном составлении Концепта, в который рекомендуется включать не только описание того, что должно быть сделано, но и упоминание того, что не следует ожидать по результатам выполнения проекта.
Опять же, в случае с SAP, следует упомянуть сервисы в рамках услуги SAP Enterprise Support. Многие компании могут ими пользоваться, но даже никогда и не задумывались об этом.
 
А про шум я, пожалуй, не соглашусь. Взять хотя бы Росатом. Если ERP упадет на одной из атомных станций, думаю, что шум может растянуться на несколько десятилетий.

Комментарий от  

Олег Чирва

  |  12 октября 2012, 10:05

Олег, спасибо за интересный пример!
 
Вероятно, на строительных контрактах заказчик не стесняется признать свою недостаточную осведомленность в силу того, что у него нет ни одного человека, который бы разбирался в строительстве. При внедрении же ERP, у заказчика есть ИТ-отдел, который может посчитать себя весьма причастным, и достаточно компетентным для надзора над проектом. Хотя внедрение ERP касается ИТ-отдела лишь отчасти, и почти ни один такой отдел не обладает достаточными представлениями ни об ERP, ни о ее внедрении (иначе они сами бы ее и внедряли). Поэтому хотелось бы поконкретнее сформулировать риски (так, чтобы они действительно "цепляли") и предложить пути решения.
 
Достаточно ли уменьшается риск приглашением третьей стороны? Каким требованиям должна удовлетворять эта "третья сторона", чтобы риски все же уменьшились?
 
Мне казалось, что в случае SAP "есть такая партия" - сервисы в рамках услуги SAP Enterprise Support. Вы так не считаете?

Тема курирования IT внедрения ERP-системы слишком заезжена – в этом варианте слишком легко проект сваливается в глобальную попытку перенести в ERP систему устоявшиеся схемы бизнес-процессов. Конечно, вероятность такого исхода можно уменьшить при реальном привлечении настоящих «ключевых пользователей».
С другой стороны, хоть FIDIC и «кричит» о беспристрастности Инженера, но, кто платит – тот и заказывает музыку, вот и получается, гарантированной беспристрастности не получить. И большой разницы в вопросе на кого полагаться Заказчику нет – хоть на Архитектора от Исполнителя, но в пределах общей стоимости контракта на внедрение, хоть на внешнего Эксперта, но за дополнительные деньги! В конечном итоге, решение по этому вопросу зависит от результатов подготовительной фазы проекта – насколько у Заказчика была возможность реально пообщаться с персоналом Исполнителя, насколько у него были возможности самостоятельно убедиться в состоятельности знаний Архитектора.
Если есть сомнения в состоятельности – вот тогда и стоит задуматься о внешнем специалисте. А критерии для выбора – наверное достаточно отзывов о реальном опыте работы в роли Архитектора на успешных проектах. А уж там, совершенно не обязательно найти специалиста с сверхидеальными качествами, в любом случае, «истина рождается в споре».
Отдельный вопрос «сервисы в рамках услуги SAP Enterprise Support» - знаете, если вести речь о проектах внедрения в Германии, США… - можно посоветовать и эти сервисы, но если речь идет о внедрениях в Украине, где за последние пару лет налоговый учет перевернулся с ног на голову (спорное утверждение, что он раньше стоял на ногах), или если речь идет вообще о первом коммерческом проекте внедрения SAP в стране (Грузия, Тегета Моторс) – вы уверены, что опыта специалистов SAP Support достаточно для корректного и полноценного участия в таком проекте?

Комментарий от  

Олег Точенюк

  |  12 октября 2012, 16:25

Михаил,
 
Спасибо, что вспомнили про Тестера в качестве "третьей" стороны.
Вы хотите сказать, что тестирование не имеет регламента?
Если Тестер способен находить ошибку за ошибкой, то флаг ему в руки!
Задача же Разработчика не только в том, чтобы сдать "в срок", но и в том, что сданное должно соответствовать заявленным характеристикам.
А здесь уже нужно вести речь о грамотном составлении Концепта, в который рекомендуется включать не только описание того, что должно быть сделано, но и упоминание того, что не следует ожидать по результатам выполнения проекта.
Опять же, в случае с SAP, следует упомянуть сервисы в рамках услуги SAP Enterprise Support. Многие компании могут ими пользоваться, но даже никогда и не задумывались об этом.
 
А про шум я, пожалуй, не соглашусь. Взять хотя бы Росатом. Если ERP упадет на одной из атомных станций, думаю, что шум может растянуться на несколько десятилетий.

Да ладно, вам.. кто ж это сказал, что SAP управляет атомным реактором?! Это ж не система реального времени, так что вряд ли такие страсти вообще возможны.

Комментарий от  

Олег Чирва

  |  12 октября 2012, 22:08

Да ладно, вам.. кто ж это сказал, что SAP управляет атомным реактором?! Это ж не система реального времени, так что вряд ли такие страсти вообще возможны.

Более того, еще и ограничения в лицензии были - не допускать в АСУ ТП

Комментарий от  

Сергей Капустин

  |  24 октября 2012, 13:18

Я уверен, что если со стороны заказчика есть заинтересованность в получении именно практического, полезного результата, то и подрядчик будет выбран нормальный, и мошенничеству нет шансов случиться. В этом плане внедрение SAP от любого другого подряда не отличается. В статье предлагается нанимать третью сторону (недвусмысленно намекая на Панораму) для обеспечения контроля за методиками, сроками выполнения проекта и вывешивания противовеса. Проблема в том, что конечный заинтересант всё-равно остаётся один - увеличивается только "обзорность" проекта.

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