вот и я говорю - сначала человеком сделайте , а потом смокинг ему примеряйте

Никто ж с вами большими и умными не спорит, никто не умаляет авторитет. Говорится о том, что многой интеграции нет и в помине, как и локализации под страну. И кастомайзить приходится по разному. И есть требования законодательства, с которыми стандартный функционал ну никак не стыкуется. И консалт отмораживается, говоря, что надо пользоваться стандартным и конкретно под нас переписывать не будут. Такая у них политика.

Есть задача и её нужно решить. Желательно в рамках стандарта и чтоб ничего не поламать. Но случаи и задачи бывают разные. А умничать можно много - за это вы и бабки получаете.

2 Uukrul


Так как выпад был откровенно в нашу сторону не могу промолчать...

a) Вы так уверенно рассуждаете о вещах, которые даже и не видели, что я начинаю завидовать Вашей самоуверенности
б) Пишем-пишем, модификаций не делаем без необходимости
в) "старших" товарищей на, скажем, модулях FS-AM, CML, СMS и т.д. Вы много видели?

Далее... Кто Вам сказал, что мы хотим утереть кому-то нос, манией величия как-то не страдаем.

Любителям стандартизации и решения всех вопросов через spro... Уважаем и применяем, но не всегда это возможно.

p.s. И наконец, господа оппоненты, беспочвенно называть людей "утиральщиками" - это слегка... неэтично

Беда в том, что стандарт мало кто знает - уж очень он большой, и наорочено там всего огромное количество. Плюс отраслевые решения и аддоны. Специалистов, разбирающихся в этом многообразии, можно пересчитать по пальцам - и подготовить такого специалиста дорого, и удержать проблематично. Гораздо легче набрать абаперов - а то и просто студентов-программеров, обучить их быстро абапу и кое-каким азам системы - и вперед, новоиспеченные консультант бежит на проект.
Еще один плюс разработки для консалтинга - клиент подсаживается на конкретного консалтера как наркоман на иглу. Стандарта минимум, разработки свои, каждый хотпак не говоря уже об апгрейде или расширении функциональности, стандартным образом не проходит - ломаются эти самые разработки. И клиент остается перед выбором - либо новый проект с откатом на стандарт - дорого. Либо другой консалтер или собственая команда - долго. Нет ничего геморройнее разбиралок в кривом чужом коде. Самым быстрым вариантом получается опять обратиться к тому самому консалтеру, который накуролесил в изначальном проекте - с одной стороны его бы в шею за такую инсталляцию, а с другой - раз уж она, эта инсталляция, есть - ее надо как-то поддерживать. Хотя опыт общения именно с внешним консалтом у меня не большой, но наблюдал я как правило противоположную картину - не клиент, а именно консалтинг настаивал на разработках. С западными компаниями этот подход не проходит - там любителям переабапить все и вся сразу указывают на дверь и придают начальное ускорение пинком в мягкое место, а вот наши пока такие решения хавают за обе щеки, а потом на каждом углу жалуются какое дерьмо этот сап.

Вполне справедливое мнение.

Как вы внедряете САП? М-м-м... Вам какой ответ нужен - какой Вы хотите услышать или то, как оно есть на самом деле? (с)

Уж сказки не рассказывайте, прсто западные компании (и некоторые наши) нанимают для разработок не партнеров а сам sap, и подсаживаются уже на их иглу.
А про написание своего функционала. его просто умело надо писать, без модификаций. FI-FM я переколбасил полностью при помощи Open Fi, но при переходе с 4.0В на 4.6С никаких проблем не возникло.

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

Ну мне тоже приходилось встречаться с грамотными разработками - когда нужную функциональность дописывают отдельно и связывают со стандартной нормальным путем - тем же Open Fi или BAPI. Но человек ленив, и всегда есть соблазн вмечто написания своего функционала и разбиралок с интерфейсам стандарта залезть в исходники и там немного погадить.

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

Господа artyom и Jedi, полностью разделяю ваше мнение

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

Смотри функционал ZFM для "Cеверозападного GSM" московкий САП разработал это примерно в 2002 году, а ни адд-она ни чего, т.е подсадили на иглу...

Хотел бы сказать какие модификации мы в основном делаем:

Например тр FM5I Создание фонда (FI-FM)
Нам не хватало полей для ведения характеристик фондов, и было принято решение о модификации.

Модификация состояла в следующем.

1. К таблице fmfincode был сделан .append (это не считается модификацией вообще)
2. В экран 200 (SAPLFM52) были вставлены поля из .append
3. В логике отсчета в chain были вставлены эти поля
Все...
Исходники не правились! все знают что сап часто делает move-corresponding...
поэтому значения в эти поля заполняются автоматом.
Ну а мы потом это используем в своих отчетах.

Когда САП проводил ревью, они не отметили это как серьезные модификации.

artyom - а это и не есть модификация - это нормальное расширение, которое поддерживается САПом. Не об этом же речь тут идет. Речь идет о той кагорте "умельцев", которые очень часто повторяют, что в САПе не предусмотрено - но мы вам сделаем все, что хотите. И клиент получает практически переписанный стандарт - или во многом переписанный, который потом только выкинуть останется. А какое складывается впечатление у клиента? А впечатление простое - [censored] ваш САП - ничего он не может - это ж то же самое, что собственная разработка. А все происходит от того, что эти "умельцы" САП не знают совсем. Здесь речь только об этом. Я сейчас для себя решила так - если у консалтинговой конторы в штатном составе большая часть абаперов - лучше с этой конторой вообще не связываться - себе дороже.

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

Мы это считаем модификацией. Тогда почти все наши модификации можно назвать расширением.

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

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



Резюмирую:

Модификации полностью нельзя отбрасывать как способ выхода из трудного положения, но этот способ должен стоять на последнем месте

Я думаю что этот принцип весьма логичен.

V® - все гораздо хуже - я тот, кто громко материться во время апгрейдов и пачирования и попыток настроить систему так, чтобы она работала Порой ОЧЕНЬ громко

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

Светлана, какими будут ваши действия, если окажется, что стандартный функционал SAP`а не позволяет реализовать конкретную задачу? Вы уверены, что SAP`ом все предусмотрено? А Большой SAP, к примеру, говорит – для реализации данной задачи используйте BADI такую-то, но метод, который Вам нужно использовать еще не написан?
P.S. Не принимаются ответы типа: Данная задача не реализуема, Эта задача выходит за рамки функционала, Обращайтесь SAP, или Вам это не нужно, никто это не использует…