Ну это же типичный ZSAP выходит...

Частично это же было рассмотрено так же и тут: sapland.ru/articles/stats

Ссылка на профиль: sapland.ru/cabinet/1857

Все замечательно, только вот фотография к Татьяне не имеет кажется никакого отношения, ну если конечно за последние пару часов ничего не случилось :-)

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

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

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

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

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

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

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

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

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

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