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

Тоже хочу поделиться своими соображениями. Есть два очень отличающихся друг от друга случая.
1. Консалтинг - тут все круто по правилам и т.д. Т.е. консультант - это человек занимающийся концептуалом настройками и т.д. Программист - человек, которой программирует имея задание от консультанта (причем очень грамотное, т.к. в консалтинге консультанты немного петрят и в программировании), но также и программист может немного помочь консультанту, т.к. знает систему изнутри. Ну и т.д.

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

Причем на все это начальству наплевать, до пору до времени.
Потом наступает время собирать камни: нет документации на программы, нет актуальных протоколов настроек и т.д. Вобщем тем кто не ушел в консалтинг приходится туго.

Не хочу обобщать, может у кого и не так дела обстоят, но в массе своей это уж точно.
[/b]

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

p.s. впрочем, это относится прежде всего к необеспеченным проектам.

по моему опыту 90% рано или поздно становятся необеспеченными.

Тут как при покупке иномарки. Сначала тратятся, а потом масло менять вовремя не удосужатся

я просто это вычеркнул )))

[Тоже хочу поделиться своими соображениями. Есть два очень отличающихся друг от друга случая.
1. Консалтинг - тут все круто по правилам и т.д. Т.е. консультант - это человек занимающийся концептуалом настройками и т.д. Программист - человек, которой программирует имея задание от консультанта (причем очень грамотное, т.к. в консалтинге консультанты немного петрят и в программировании), но также и программист может немного помочь консультанту, т.к. знает систему изнутри. Ну и т.д.

2. Проект на самом предприятии. Вот тут часто бывает полная каша:
[/b][/quote]

Абсолютно согласен. Собственно поэтому и родился вопрос. На предприятиях зачастую один человек формирует задание, пишет код и делает настройки.

А консультант как образованный человек должен знать чем append от collect-а отличается?

Это путь в никуда (для предприятия). Но очень эффективный (для того, кто "формирует", "пишет" и "делает").

Не должен.
Достаточно знать что есть встроенный хелп, где всё это описанно.

PC WEEK 2004 №35(449)

Есьб статейка на странице 47 есть статейка "Разобрался с сервисами - приступай к ERP-внедрения"

Тут проекты на предприятии делятся на уровни, довольно интересно...

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



Это я в подтверждение слов skif-а

К вопросу распределения обязанностей:
Помогите советом, pls. Прихожу я в компанию на собеседование, занимаюсь FI, они говорят: у нас ведут по 2 а то и по 3 модуля консультанты, но предложили ММ, правда приняли что нет знаний в этой области, готовы подучить, не знаю стоит ли распыляться на это направление или нет? FI к ММ не близко, если бы СО предложили-другое дело. что посоветуете?

Ну, тут сразу сказать сложно Я как логист не взял бы финансовый модуль с нуля... Смотри сам. ДУмаю, после FI ММ тебе довольно простеньким покажется, если займешься