Не флуда ради хотел спросить. Появившись, например, на новом месте работы, смогли бы вы определить, кто занимался здесь BW до вас: опытный человек или начинающий?
Другими словами, есть ли какие-то особенности в настройках, в организации процессов, в построении отчетов, отличающие мастера от новичка?
Такие вещи как-то не описаны ни в курсах, ни в Best Practices. Было бы интересно узнать, к чему нужно стремиться, и каких типовых ошибок и "кривизн" избегать.

заходишь в табличку TADIR , набираешь в поле AUTHOR имя PERISHKIN и F8, если записи найдены, то с проекта надо срочно валить, роняя кал...

YM - Интересно, а Вас как обучали - на курсах, с наставником, постепенно показывая все прелести БВ, или же как щенка на недоделанный и дважды переделанный проект бросили - выплыви, если сможешь, интернет (хорошо, если есть) тебе в зубы? Подумайте, прежде чем кого-то обвинять в плохих разработках, не говорят ли то же о Вас?
Kubus - если слишком много Z в BW, а в R\3 их почти нет - есть подозрение на "ламера". Хотя, на мой взгляд, опаснее ситуация передачи проекта из рук в руки - обследование и ТЗ писал один, причем не очень опытный, потом свалил, а реализовывали 2-3 последовательно. Если новичок начал, новичок закончил и как следует задокументировал - не так страшно.

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

вот насчёт того, что если много Z в системе то это плоховато - не согласен, мало ли кто и как адаптирует сап под свои нужды и наоборот.

Это при условии что в р\3 их тоже много, норм... А вот когда тока в БВ - надо глядеть, почему.

имеются у сапа клиенты, которые сразу начинали с BW , без R/3.

Я бы еще предложил такие признаки:
1. Чем меньше число разных инфо-провайдеров, на которых построены отчеты системы, тем лучше (исключая мультикубы - на мультикубах должны быть построены только те отчеты, для которых дествительно требуются данные из нескольких кубов, т.е. ситуация, когда все отчеты построены на одном мультикубе, по надобности и без надобности, может быть не самой оптимальной, хотя, может быть, предыдущему разаработчику могло бы просто лень их делать на разных кубах, особенно, если часть показателей одинаковая во многих отчетах)
2. Отсутствие всяких лишних признаков, объектов, провайдеров, исключая разве только прослоечные одс, которые делаются для того, чтобы максимально быстро (без преобразований) забрать данные из исходной системы и потом уже обрабатывать их на стороне BW.
3. Если работать удобно после человека - значит работал профессионал выского класса!

а потом возникают вопросы: Ай-спасите-помогите: как перетащить запрос с одного куба на другой... а этих запросов - тыща

Лень - это хорошо, меньше времени надо тратить на разработку => можно чем то другим в рамках проекта заняться...

Позвольте не согласиться.

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

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

Это тоже не показатель, возможно работал <я не знать русский языка> с такими-же знаниями и взглядами на жизнь

Я так думаю, если система широко используется и пользователи не кроют её в кулуарах матом, то как минимум делал её грамотный специалист.

А вот еще: чем меньше своих объектов в системе, тем лучше. САП ведь, скорее всего, не один день думал по поводу бизнес-контента...

Если мало своих объектов - значит, чел разобрался с бизнес-контентом, знает, как его использовать. Т.о. будет меньше ошибок в системе, быстрее сроки внедрения...