Дамы и господа.Просмотрел весь форум, но так и не нашел ответа.
Задача переход с 4.6 на 6.0
В данный момент проект консультантами оценивается в 100 человеко дней.
Адекватен ли этот подсчет?
И сколько примерно составляет бюджет подобных проектов.
Спасибо.

Продуктивный функционал, количество Z-разработок, количество использованных Z-инклюдов, формат проекта.. Всё влияет.
Одно дело - сделать технический апгрейд, другое - задокументировать и переписать весь Z, переделать на стандарт часть Z и т.д.

полагаю да, особенно если Z*-ов много.

а то и офигительно мало

100 челодней - это 10 консов за две недели апгрейд системы готовы сделать?
Там реально работы на полгода по анализу быдлокода и его совместимости с новыми структурами данных. Во многих предметных областях етсь возможность замены быдлокода, созданного для покрытия дефицитов старой версии, на стандарт в новой версии. Нужно тестировать много чего в большом объеме.
Каждый клиент переживает апгрейд не чаще раза в 5-8 лет. Некоторые консультанты с 10-летним стажем ни разу не делали апгрейд. Поэтому тем более становится ценным опыт SAP Active Global Support, который по тысяче с лишним апгрейдов в год помогает клиентам апгрейдить системы. Посему имеет смысл при апгрейдех не жадничать, привлекать эту службу. Недавно столкнулся с ними на своем проекте. Очень толковые ребята, много русскоязычных консультантов из Германии. Указали в такие тонкости, о которых сам ни в жизнь не догадаешься.

Наткнулся на пример проекта стандартного перехода 4.6-6.0
Скажите, справедливы ли эти цифры ибо они отличаются в меньшую сторону (человеко дней) от предложений отечественных консалтеров.

*Preparation Phase* *6 days*
Kick Off Meeting 1 day
Upgrade Project Procedures Preparation 1 day
Prepare Upgrade Project Plan 1 day
Technical Requirements Assessment 3 days
Assess Training needs of Key-users & End-users 1 day
Prepare Detailed Basis Activity List for DEV, QA & PRD 1 day

*Business Blueprint Phase* *6 days*
Develop System Landscape Upgrade Plan 1 day
Functional Requirement Checklist 1 day
ABAP Development check list 1 day
Develop detailed Training Procedures & Documentation for Key Users & End Users 1 day
Identify Testing Scope & Scenarios 1 day
Identify Authorizations Conversion to Roles for SAP ECC 6.0 2 days
Develop Documents as per Basis Activity List 1 day
Develop Authorization Matrix for Activity Groups to Roles Conversion 2 days
Prepare Upgrade Deliverables Checklist 1 day

*Realization Phase* *28 days*
Installation of Solution Manager 3.2 System 1 day
Creation of New Development System for Upgrade Project (Homogenous System Copy - PRD) 2 days
Upgrade to AIX & Oracle 10g, SAP ECC 6.0 on New Development Server 3 days
Upgrade Frontend Software 4 days
Perform SPAU & SPDD Corrections 5 days
Perform ABAP Development & Corrections 10 days Perform Authorizations Conversions and corrections after upgrade 8 days
Perform Upgrade Testing for each Application Module 7 days
Perform Unit & Integration Testing 6 days
Perform Training to Key Users & End Users (Generic & Specific) 3 days
Upgrade to AIX, Oracle 10g, SAP ECC 6.0 on Quality System 1 day
Homogenous System Copy of PRD to New Quality & Upgrade to AIX, Oracle 10g & SAP ECC 6.0 2 days Perform Testing in Quality System 3 days
Testing by end users on Quality System 1 day

*Production Realization & Go-Live Phase* *6 days*
Upgrade to Production System Operating System to AIX (after close of business hours - 23:00) 1 day
Oracle Upgrade to 10g (after close of business hours - 23:00) 1 day
SAP Release Upgrade to ECC 6.0(Downtime Minimized - Downtime occurs in non-business hours) 2 days
User Acceptance Testing 1 day
Production System Go-Live 1 day

*Post Go-Live Support* *14 days*
Post Go-Live Support 14 days Note: This is high level plan subject to change during Business Blue Print Phase 0 days

Так возьмите хотя бы этот план, уберите дни и пройдитесь с PM-ом, пусть расскажет вам по каждому пункту.

Пример:
User Acceptance Testing 1 day

Был случай этот пункт занимал 20 mans-day (прогнали весть бизнес без закрытия года). Реализация силами ключевых пользователей. Вовлечение консультантов на уровне 1-2 mans-day (фикс прайс) и то, только из-за не ратифицированного SLA на тот момент, а то можно было бы free of charge организовать.

В некоторых местах - забавно. Например обновление софта на фронтэндах - 4 дня.
А в целом - составлено западными людьми для западных людей.
Наивно полагать, что не будет отличий.
Швейцарцы вон удивляются срокам внедрения руского функционала по FI. Которое (внедрение) они за неделю делают. И им достаточно сложно объяснить почему в нашей стране все немножко по другому.
А самое забавное будет переводить то, что называлось русским add-on'ом в 4.6 на то, что сейчас есть в 6.0.
Да и с печатными формами будет интересно переходить.
По некоторым прикидкам параллельное внедрение 6.0, с повторением настроек в привязке к новой реальности, может оказаться быстрее и дешевле.
Тем более, что в большинстве случаев надо будет апгрейдить железо. То, на чем работает 4.6 далеко не всегда потянет 6.0
И это мы еще не говорим про технический апгрейд, который, в случае большого количества исправленных стандартных объектов (что, кстати, практически никогда не наблюдается на западных внедрениях), будет весьма не тривиален и сильно трудоемок. Причем на это время придется постоянно привлекать и консультантов и ключевых пользователей. А большую часть исправленных объектов вообще не получится идентифицировать на тему кто и зачем их правил. Что приведет к увеличению сроков тестирования.

Скорее всего, неадекватен.

Риску предположить, что это либо сделал Ваш текущий интегратор, который представляет себе количество доработок и архитектуру систему, но хочет Вас убедить перейти на новую версию, осозновая все риски проекта по переходу и вероятное отсутствие маржи с данного проекта. В данном случае я бы согласился.

Второй вариант - это другая компания интегратор, которая хочет видеть Вашу компанию в списке своих клиентов. В дааном случае они, скорее всего, также предвидят сложности в данном проекте, риски и возможную убыточность проекта, но готовы вложиться за имя Вашей компании - возможно, это даст шанс выиграть тендер на другом проекте, более крупном и маржинальном.

Третий вариант, что эти 100 дней использованы как "приманка", чтобы начать проект, притормозить его и тянуть деньги за обычный и платный консалтинг - маловероятен. Договор, судя по всему, имеет четкие фунциональный рамки и временные границы, да и проекты по переходу более предсказуемы и менее рисковые.

Вероятность четвертого варианта, когда компания хочет просто сделать вам проект и получить с него прибыль, я очениваю еще ниже, чем третий вариант

Вам сделали неплохое предложение. Просто прочитайте внимательно контракт: что входит в скоуп работ. И поговорите в управляющим компании - внедренца начистоту.

Удачи в переходе. Дело нужное!

С Уважением,
Георгий