Изменения в какой стандартной саповской проге могут с бОльшей долей вероятности привести к неконсистентности наибольшего числа таблиц за наименьший промежуток времени?..
Это к вопросу каким образом нужно контролировать получение ключей на изменение стандартных объектов разработчиками

лезть можно куда угодно, но с умом
вообще, думается, все что связано с финансами породит больше всего проблем, по сему, наверное, пакет fbas - там все "чувствительное"

а если хотите "убить" систему, попробуйте потрогать sapmssyd

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

Правда с появлением неявных точек расширения проблема ключа не столь актуальна, как подобная неконтроллируемая модификация стандарта.

Что касается неконсистентности таблиц, то тут достаточно прамого обновления в Z-отчётах или где-нибудь в UE/badi, можно обойтись без ключа.

интересная у вас предельная теорема.
Так то и без всяких ключей можно наваять код, который со 100% вероятностью покалечит данные.

Имхо, если и контролировать, то характер изменений, целесообразность с точки зрения поставленной задачи, а не сам факт получения ключа.

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

Да, и еще: есть такой очень @%$@# способ модификации стандарта, как копирование чуть ли не всего пакета в Z-й , а там уже - полет фантазии разработчика безграничен. И оправдание всегда - "неее, мы же стандартные проги не трогаем, обновление пройдет на ура...". Поубивав бы...

Хм, не разъясните подробнее вот это:

Что за"неявные точки"? Имеется ввиду что-то кроме customer-, user-exit, BAdI и т.п.?

Имеются в виду enhancement point в erp2005, которые позволяют без всякого ключа вставить свой код в начало и конец любого ФМ и в массу других мест.

ИМХО, нормальная процедура получения ключа такая:
1. функциональный консультант запрашивает ключ. О необходимости запроса ему может сообщить абапер, но запрашивать должен обязательно консультант.
2. руководитель группы разработки получает запрос и подтверждает, что получение ключа оправданно
3. базисник получает ключ, отсылает его консультанту.

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

Схема + данное требование = Зачот! Надо запомнить...

+1. У нас так и было сделано. Модификации (то, что в народе называется "core mod") позволялись только в случае, если ну вообще нет никакого другого выхода, а нужно выполнить какое-то обязательное (по закону, например) требование. Требовалось обоснование за подписями важного начальства, а также свидетельством функциональщика и ABAP'ера, что, мол, да, изрыли все вдоль и поперек и по-другому никак нельзя.

К вопросу о ключах - а ключи иногда требуются как бы не совсем для модификаций, а, например, для VOFM routines или user exits в SD (которые несколько нестандартно сделаны). Выдачей ключей у нас заведовал Technical Team Lead.

to Jelena: Да, вроде как и не модификации, но нужно помнить, что за SAPом всегда последнее слово:

Последнее кстати тоже может являться весомым аргументом в отказе на модификацию (любую).