+N

Я уже пытался это сказать, но наверное выразился не достаточно точно.

Допустим, для того чтобы решить конкретную задачу тебе нужно знать в какой таблице лежат данные (пишешь ТЗ если ты конcультант, разрабытаваешь отчет если ты абапер и тебе не повезло с постановщиком, ну или ему повезло с тобой). С точки зрения конечного результата абсолютно серавно как ты получил нужную тебе информацию: знал заранее, сделал /h, воспользовался SQL трассировкой, нажал F1 в нужном месте, покапался в словаре данных, спросил у более опытного товарища, задал вопрос на форуме... и т.д. и т.п.

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

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

Вот они золотые слова!!!

+1. Золотые слова. Я тоже так всегда говорю.
А космические корабли, рассекающие просторы Большого театра, оставим космонавтам и балеринам.

Просто и понятно, еще не значит производительно... Мне вот интересно, много у нас программистов-самоучек, которых в институте программированию не учили?

а чем повредит то?

ну не надо говорить, что решение проблемы того кто не знает систему из нутри вообще, будет всегда лучше!

а что тогда остается консалтеру сап только сидеть настройки делать?

полное убожество скажу тогда я вам, как кодер у программистов Laughing

отличие бизнес консультанта от консультанта сап лишь в том, что он круче знает все эти фишки, но почти или совсем не знает систему. IMHO

Чем проще - тем надежнее. Знаете, почему автомат Калашникова самый популярный в мире?



IMHO, таких большинство.

Вы сами ответили на свой вопрос:



Задача SAP-консультанта - знать систему, и как на нее наложить бизнес, который придумал бизнес-девелопер .

В идеале так и есть, когда есть отдельные БК

Но, чтобы обычному консультанту нормально общаться с БК он как раз и должен все это знать, ситуация аналогичная с девелопером, должны быть общие точки.

За частую при должном опыте и знаниях можно обойтись без БК(обычно они со стороны заказчика в виде ки юзеров) одним консультантом SAP с хорошим опытом.

При нормальном внедрении SAP часто меняется именно сам бизнес, а не система под бизнес натягивается, кто знает тот поймет.

Абсолютно точно. Все единообразно.


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


Это в идеале . А обычно как раз наоборот.

Вы еще спросите, многие ли из тех что учились программированию в институте, в итоге научились проектировать нормализованные базы данных и осознали, как работают указатели в Си.
По моим ощущениям - процентов 5, ну максимум 10.

вменяемые заказчики как раз меняют бизнес под систему где это возможно и не имеют много проблем в последствии с эксплуатацией системы.

для сапа не нужно этого всего знать...

стронг девелопмент существует где угодно но не при внедрении сап

И с хранилищами данных та же беда. Иной раз ТАКОЕ налеплено, что в голове не укладывается - как будто не просто небрежно делали, а еще специально гадили...

Встречный вопрос. А вы знаете, что автоматом калашникова нельзя сбить самолет? Т.е. можно, но только при совсем уж сказочных условиях. Я не сказал, что программировать надо сложно. Я лишь сказал, что для каждой области есть свои подходы. И иногда проще написать сложно (хороший каламбур) через пару классов, чем через двадцать SELECT-ов... Как бы непроизводительно это не было.