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

И еще вопрос: каким образом можно понять, хотят ли оставить до конца на данном месте или есть перспектива? Интуицией?

вроде как полно позиций для стажеров......



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

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

какой город? или я просмотрел и уже было?

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

Санкт-Петербург

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

в идеале всё должно быть в соответствии с ASAP
всё это богачество должно поддерживаться с помощью SAP Solution Manager
для анализа активированных бизнес-процессов предполагается использовать инструментарий Business Blueprint разработанный в сотрудничестве с IBIS Prof. Thome AG. но этот инструментарий не развивается с весны прошлого года. вероятно из-за PowerDesigner
всё это богачество изучается на курсах SMI210 SMI310 и на открытых курсах Rapid Deployment of SAP Solutions и Business Process Modeling and Analysis

это в идеале

а на практике невозможно провести интеграцию между ERP Best Practics и Solution Manager, чтобы создать прототип проекта для дальнейшего ведения проекта. и сотрудники САПа на вопрос относительно этой проблемы пока за последний год никакого ответа не дали.

как то так...

Уважаемый Джек, ну зачем вы грузите топикстартера - методолога по управлению растратами, методологией и тулзами по проектной бюрократии. Методологу по растратам нужно знать вот что:
1. Начинать писать свою методологию нужно с похода на википедию. Там прочитать, что такое элементы затрат, виды затрат, типы затрат и другие умные слова про способы структурирования затрат. В своем документе Методология нужно для начала придумать собственную терминологию. Все имеющиеся в мозгу методолога способы структурирования затрат, почерпнутые из экономического образования и википедии, следует перемешать с помощью Великого Рандома: элементы обозвать типами, типы - видами, виды - элементами. Чтобы методология получилась уникальная.
2. Не надо придумывать методики калькуляции себестоимости для типов и тем более партий готовой продукции. Достаточно месторождения/завода/трубы целиком.
3. Ни в коем случае нельзя вести отдельный учет затрат по отделам административного аппарата. Это покажет, что все затраты на дОбычу/переработку/транспортировку в основном состоят из содержания заводоуправлений и их подрядных инвестиционных консультантов, аудиторов, саперов, а также всяких прочих ISO over 9000, Lean Manufacturing, Six Sigma, Kanban, TQM - консультантов.
4. Чтобы затраты на саперов попали на производство, а не административку, нужно придумать методологию отнесения таймшита от консультанта ТОРО на продукцию основного производства. Естественно, без [s]деривации[/s] [s]аллокации[/s] [s]разблюдовки[/s] распределения по заказам/партиям/продуктам в этом самом производстве.
5. Никогда не беритесь писать методологию определения прибыльности продуктов. Все кому положено и так знают, почему один газ идет на факел, а другой - в трубу. А за себестоимость конденсата вам еще и голову открутят, если по вашей методике кто-то что-то насчитает. Поэтому учитесь писать обоснование, почему формирование методологии калькуляции себестоимости по видам продукции нецелесообразно.
Пока отключаюсь.
В таком виде полезно сформулировано?

Sedlo, спасибо. Сформулировано полезно. Сразу чувствуется, так сказать, знание подноготной.

like!

2 Sedlo
Респект

Все перечисленное господином Sedlo, способно сделать из практически любого человека матерого методолога. На ведь наша цель – стать зубром-консультантом, желательно не менее матерым. Кроме того нужно обеспечить незаменимость на проекте и как следствие постоянный источник материальных плюшек. А также необходимо, чтобы начальство приходило в ужас от одной мысли, что вы можете их покинуть.
Чтобы стать зубром – нужно делать следующие вещи:
1. Опровержение чего-то традиционного, устоявшегося, косного и замшелого.
Однако таких людей, любящих критиковать и ничего не предлагающих взамен – огромное количество, а мы должны возвыситься над чернью. Из этого вытекает:
2. Предложение чего-то своего, новаторского и революционного.

Это рецепт и путь к славе. Я даже могу предложить несколько таких связок, которые, на мой взгляд, безотказно сработают практически на любом крупном российском проекте.
1. Создание FI – документов из фактур ММ и SD. Однозначно вчерашний день, идеи бесшовной интеграции давно устарели, к тому же по слухам даже контрагента поменять практически невозможно при этой проводке в FI. Что нужно: интерфейс с OLAP системой (лучше через PI), с обратным созданием FI-документа через IDOC.
2. Расчет амортизации в FI-AA морально устарел еще при создании. Что нужно? Ответ очевиден: перевести его в CO. Свежая и оригинальная идея – МВЗ это ОС, для расчета амортизации идеально подходит такой инструмент как распределение.
3. Заявочная компания требует кардинального переосмысления. Названия некоторых таблиц прямо противоречат духовным скрепам. В Питере это особенно актуально – поэтому переделываем целиком и все. Вообще выносим из SAP и переносим в HP Service Desk – там заявки тоже есть! Оттуда в OLAP, там агрегируем, сагрегированную массу обратно в SAP, конечно в виде Z таблицы, с как можно более длинным ключом, чтобы легче было ссылаться.
Реализация хотя бы одной из этих идей гарантирует постоянную занятость на проекте, заработную плату существенно превышающую ЗП самого главного методолога и, помимо этого, широкую известность в узких кругах SAP-консультантов.

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

незаменимость на проекте при этом гарантирована!

p.s. это был стеб, наболело

а может просто предложить совсем волшебный способ - "у нас есть эмулятор 1С - 1Z Buhgalteria 7.7 внутри САПа + методика его внедрения"?
к методике прилагается "пожелатор"(набор опций по активации функционала с стиле "чего изволите?")