Вы сделали руководителю круговую диаграмму, она отображает факт. Вас просят, отобразите мне тут же, план, чтобы я мог сравнить... Буду признателен за предложение по визуализации.
Обратите внимание на фразу "Если вы не решаете задачу просто “быстро показать какие-то цифры”, а смотрите немного на перспективу,...", она является ключевым ответом на ваш комментарий.

Однако вместо простой круговой диаграммы предлагается диаграмма состоящая из 12 столбиков, шрифтом из разряда вырви глаз, хрен его разберет что там написано вместо того чтобы сделать круговую диаграмму, так любимым серым и добавить туда надпись более детального заголовка. А по поводу сравнения, не спорю, сравнивать круговые диаграммы по годам не очень кошерно, но ведь задача стояла вывести распределение выручки за указанный год,а не распределение выручки за период с года хххх по год yyyy, т.е. таким вот хитрым финтом используя подмену понятий выводим доказательство что круговые диаграммы нельзя использовать, не говоря уже про дальнейшие сравнения план/факт, что уже является третьим отчетом. Но как лично мне, то картинка 2 (где выведена круговая диаграмма и столбик), как раз показывает что круговая диаграмма в данном случае более наглядная, чем столбик, так как соотношение экрана у нас ширина больше длинны, это раз, значит шрифт круговой диаграммы можно сделать больше а это более читаемо, и никто не мешает вывести вам ваши 42% в круговой диаграмме. Единственное, что может я бы сделал сортировку секторов от меньшего к большему, а не как у вас когда меньшие сектора чередуются с большими, а то в столбике вы как раз сделали такую сортировку, так что мешало сделать это в круговой диаграмме? Кстати, если прочитать вашу предыдущую статью "Упрощение дизайна отчетов по стандарту IBCS", то вы как-то сами себе противоречите, там вы за минимализм и столбики у вас широко, а тут вы натолкали столбиков вагон и что там написано, даже на экране плохо видно, а уж через проектор, вообще никто ничего не разберет. Так что используйте круговые диаграммы, главное понимайте для чего вы их используете и как. Все должно быть уместным.

Интересная статья, спасибо.

Олег, а где же ответ по существу?
Охаяли чужую работу без аргументов.
 
Рассуждения о том, что, мол, такие атаки делать никто не будет - это несерьезно.
 
А низкопроизводительный z-код в sap query - это вообще через раз (от числа инфонаборов с z-кодом).

а что же случилось с 3ей главой?)

Ну вот видите вы уже про ATC вспомнили, уже хорошо. Что же касается про ваше конкретно, то если у вас такие большие проблемы с деструктивным поведением ваших разработчиков, то может проще с ними распрощаться? Я за все время лет уже 15 как или чуток больше, с таким поведением столкнулся один раз, пару месяцев назад, пацанчики решили нагадить у одного клиента, но это как-то тупо, там же, кто, когда, все же ходы записаны это раз, и два, данные действия попадают под статью уголовного кодекса вмешательство в работу программ и сетей и т.д., так что посадить или нет, это уже личное дело заказчика.
 
Кстати, обойти вот эту вашу проверку, включения в программу, в явном виде текста для генерации программы, можно без особых проблем и дальше что? Ну т.е. если кто-то очень захочет что-то поломать, то поверь он это сделает, в остальных случаях типа по незнанию, так тупой UPDATE с ошибкой в ключах завалит систему гораздо быстрее, чем вот эти вот извращения с самогенерацией вредоносного кода, а это иногда даже тестирование не может выловить. Так что SafeERPCodeSecurity это баловство, но чем бы барин не занимался, лишь бы в работу не лез. По поводу же ATC так сказать не могу, так как данные проверку позволяют более, менее приводить код подрядчика к общему стандарту, так что тут пользы как по мне больше.

Олег, насколько мне известно некоторые компании как раз пишут собственные сценарии к SCI.
Рад, что смог объяснить, возможно, не совсем явный посыл о том, что стандартные инструменты проверки ABAP-кода к сожалению не проверяют весь ABAP-код:)
А у SAP теперь есть платный CVA, так что за деньги будет больше качественных(насколько это возможно) проверок

1. Угроза добавления SAP_ALL и дописывание кода в квери влияющие на производительность это несколько разные вещи. В первом случае это явно операция взлома системы, во втором это ошибки разработки на абап. Я просто это прочитал статью как как средства борьбы с несанкционированным доступом к системе, кстати реклама SafeERPCodeSecurity, меня как раз и утвердила в этом мнении, а не как оптимизация разработок.
 
2. Да согласен, что ATC это больше рекомендации, причем не всегда корректные.
 
3. Ну ATC тут просто не даст деблокировать запрос, который не прошел SCI. А причина запрета это может быть как вредоносный/не правильный код, так и требования приведения текста программы к единому виду. Хотя у меня сложилось впечатление, что SAP как обычно сделал и забил на тот же SCI. Ну что мешало добавить экзиты для включения в проверку пользовательских расширений. Работы на день, зато получаем универсальный инструмент, который можно расширить и настроить под себя. Но нет, зачем же об этом думать. МЫ лучше через лет пять сделаем какой нить экстендед SCI :-)

Олег, бесспорно если ставить цель порушить систему, то способов найти можно немало.
В данной же статье на вполне понятной угрозе присвоения профиля SAP_ALL доносится информация о том, что код в данных объектах проверке стандартными средствами не подлежит.
Лично сталкивался с такими дописываниями SAP query, вследствие которых производительность отчета на выходе оставляет желает лучшего.
К сожалению механизм реализации "того же самого ATC" в части использования SLIN и SCI оставляет желать лучшего, не говоря уже о количестве и качестве проверок, которое даже в CVA весьма невелико по сравнению с конкурентами.
А приведение кода к общему стандарту можно было и до ATC в код инспекторе сделать, чем правда редко кто пользовался, к сожалению.

Ну вот видите вы уже про ATC вспомнили, уже хорошо. Что же касается про ваше конкретно, то если у вас такие большие проблемы с деструктивным поведением ваших разработчиков, то может проще с ними распрощаться? Я за все время лет уже 15 как или чуток больше, с таким поведением столкнулся один раз, пару месяцев назад, пацанчики решили нагадить у одного клиента, но это как-то тупо, там же, кто, когда, все же ходы записаны это раз, и два, данные действия попадают под статью уголовного кодекса вмешательство в работу программ и сетей и т.д., так что посадить или нет, это уже личное дело заказчика.
 
Кстати, обойти вот эту вашу проверку, включения в программу, в явном виде текста для генерации программы, можно без особых проблем и дальше что? Ну т.е. если кто-то очень захочет что-то поломать, то поверь он это сделает, в остальных случаях типа по незнанию, так тупой UPDATE с ошибкой в ключах завалит систему гораздо быстрее, чем вот эти вот извращения с самогенерацией вредоносного кода, а это иногда даже тестирование не может выловить. Так что SafeERPCodeSecurity это баловство, но чем бы барин не занимался, лишь бы в работу не лез. По поводу же ATC так сказать не могу, так как данные проверку позволяют более, менее приводить код подрядчика к общему стандарту, так что тут пользы как по мне больше.

Олег, в ATC настраивается проверка pdf и lsmw? Где конкретно не подскажете?

Вообще-то все это настраивается в транзакции ATC. А то по описанному вами пути через SE03 как-то сильно ограниченная настройка, точнее там просто включается проверка, а вот настройки правил проверок там как раз нет.
 
В общем мне это напоминает индусские статьи. Вроде как и по делу, а сядешь делать по ней, а там опачки, а важная деталька просто не описана, зато очень подробно описано, то что и так ясно, типа как создать в настройке новый завод + три экрана к этому шагу. Ну и соответственно вроде как и полезно, а использовать никак. Или это как у Шнура в песне про выборы, вся песня писалась ради последнего абзаца, посвященного SafeERPCodeSecurity? Если да, тогда написано хорошо.

Молодец Тимур!
Ждем следующих публикаций! Удачи!

Здарова! Тимур. Не ожидал тебя тут увидеть :)