Статья написана с точки зрения программиста. Прокомментирую с т.з. консультанта.
Несколько раз я пытался писать спеки подробно, как написано в статье. И что же? В большинстве случаев сталкивался с тем, что абапер некоторые алгоритмы менял (как ему проще), а что-то вообще пропускал. В итоге все сводилось к тому, что я открывал код программы и либо сам менял, либо пытался на пальцах объяснять что требуется.
Короче говоря, все сводится к профессионализму программиста. Если толковый, то все будет хорошо, если же "зеленый", то хоть как описывай в ТЗ - все равно придется сидеть и тыкать в экран.
 
Хочу упомянуть еще и о взаимодействии с абапером. Рекомендую такой стиль: лучше разбить разработку на части. Кусок программы написал, давай посмотрим, что сделано и как - по ходу исправляем ошибки.
Просто зачастую бывает так: абапер получает ТЗ, полностью его выполняет, как сам понимает, а потом выдает тебе "Я сделал", после чего понимаешь, что реализовано совсем не так, как надо. Отсюда огромные потери во времени.

Не упомянут очень важный момент:
Из RW-интерфейса (логистика, касса, HR) момент замещения "Документ полностью" не отрабатывает. Для этого можно использовать OpenFI событие 1120. SAMPLE_PROCESS_00001120 - универсальный ФМ, срабатывает всегда при создании документа отовсюду, но OpenFI выходит за рамки данной статьи:)

Олег, HANA - это в первую очередь БД in-memory, но плюс кое что еще. Можно посмотреть видео на этот счет на saphana.com/community/learn

SAP HANA это в первую очередь железка из 1ТБ оперативки где крутится собственная база данных, которая бэкапится на жесткий носитель. Официально HANA - программно-аппаратный комплексю

Как правильно понимать термин "SAP HANA" ?
это база данных in-memory?
 
или это ПО, обеспечивающее репликацию данных?

Как правильно понимать термин "SAP HANA" ?
это база данных in-memory?
 
или это ПО, обеспечивающее репликацию данных?

Данный вопрос хотел более подробно отразить в следующей статье, так как во-первых довольно частый вопрос и однозначного ответа на него нет даже у SAP AG. Во-вторых, думаю именно в сравнении с IM более явно отразятся возможности PPM.
Но все же, Олег, отвечу по пунктам:
- в качестве отчетов в PPM можно использовать dashboard с выводом на них информации по интересующим проектам, аналитикой и индикаторами. По сути, дашборды - это те же ALV со всеми соответствующими функциями (сортировка, ранжирование, фильтрация, пользовательские форматы и т.д.). Помимо этого есть встроенный инструмент BCV, который позволяет строить диаграммы. В компоненте cProjects присутсвует набор преднастроенной отчетности (сроки, ресурсы, работы и т.д.). Естественно, BI необходим для построения отчетности по заказчика и гибких аналитических форм
- не обязательно поднимать Enterprise Portal, можно ограничиться NWBC, который не является отдельной системой и при работе в "толстом" клиенте отлично справляется с одновременной работой с Web-приложениями и транзакциями в GUI
- ограничение по количеству уровней действительно не критичное ограничение. Более важным является возможность построения альтернативных иерархий портфеля. Это позволяет структурировать проекты по различным категориям и по этим критериям строить отчеты, агрегировать финансовые показатели. Например, мы можем сделать иерархию по географическому местоположению проектов и смотреть по федеральным округам, можем сделать иерархию по видам деятельности и смотреть показатели по ним. То есть одновременно смотреть на портфель проектов с разных позиций
- что еще? навскидку в PPM можно отслеживать жизненный цикл проекта (сроки и статусы прохождения стадий проекта, построение gate моделей), планировать мощности проекта, более детально планировать финансовые показатели (как напрямую в PPM так и на основании данных из ERP), проводить оценку проектов на основании анкетирования и моделей оценки...
 
Ну вот, уже половину статьи написал :)

Данный вопрос хотел более подробно отразить в следующей статье, так как во-первых довольно частый вопрос и однозначного ответа на него нет даже у SAP AG. Во-вторых, думаю именно в сравнении с IM более явно отразятся возможности PPM.
Но все же, Олег, отвечу по пунктам:
- в качестве отчетов в PPM можно использовать dashboard с выводом на них информации по интересующим проектам, аналитикой и индикаторами. По сути, дашборды - это те же ALV со всеми соответствующими функциями (сортировка, ранжирование, фильтрация, пользовательские форматы и т.д.). Помимо этого есть встроенный инструмент BCV, который позволяет строить диаграммы. В компоненте cProjects присутсвует набор преднастроенной отчетности (сроки, ресурсы, работы и т.д.). Естественно, BI необходим для построения отчетности по заказчика и гибких аналитических форм
- не обязательно поднимать Enterprise Portal, можно ограничиться NWBC, который не является отдельной системой и при работе в "толстом" клиенте отлично справляется с одновременной работой с Web-приложениями и транзакциями в GUI
- ограничение по количеству уровней действительно не критичное ограничение. Более важным является возможность построения альтернативных иерархий портфеля. Это позволяет структурировать проекты по различным категориям и по этим критериям строить отчеты, агрегировать финансовые показатели. Например, мы можем сделать иерархию по географическому местоположению проектов и смотреть по федеральным округам, можем сделать иерархию по видам деятельности и смотреть показатели по ним. То есть одновременно смотреть на портфель проектов с разных позиций
- что еще? навскидку в PPM можно отслеживать жизненный цикл проекта (сроки и статусы прохождения стадий проекта, построение gate моделей), планировать мощности проекта, более детально планировать финансовые показатели (как напрямую в PPM так и на основании данных из ERP), проводить оценку проектов на основании анкетирования и моделей оценки...
 
Ну вот, уже половину статьи написал :)