Team starts by reviewing documentation tool for

Item 4: An example on how to

documentation completeness

Review requirements and identify

corresponding Data Model (InfoCube/ODS) Tool decide which reports should be
in R/3 or the legacy system.
D1 D1a
Is report Is this a true Communicate to
Yes No
documentation reporting bus. leader
complete? need

Yes

No D4
D2 D2.5 D3
Is the report
Is this Does data exist Significant
No No No system
an Intraday in "in-scope" models number
resource
Request additional report? Infocube/ODS of users? No
intensive?
input from Business
Team member
Yes Yes
Yes R/3 is selected as
Reporting Tool
R/3 is selected as and documented
Reporting Tool A2
Total Cost of in doc. tool
and documented
Responsible Ownership
Team member Analysis
acquires/documents
additional information R/3 is selected as
Communicate final Reporting Tool
disposition D8 No and documented
Is BW cost in doc. tool
Yes effective?

D5 BW is selected as
Reporting Tool Communicate final
Does Yes
and documented disposition
Yes Standard R/3 No
content in the documentation tool
exist? D9
BW is selected as R/3 Tool
D6 D7 reporting tool and Change Selection
Does Is it less Communicate final Request is submitted if Process
Standard BW No expensive to disposition the scope changed
content create in
exist? No
R/3?
Standard Report
Yes Yes R/3 Writer

BW is selected as BW is selected as Communicate final ABAP/

R/3 is selected as Query Other
Reporting Tool and Reporting Tool and disposition Custom
Reporting Tool
documented in doc. and documented documented in doc.
tool in doc. tool tool
A3
Sub-Process Report Consolidation &
Communicate final Communicate final Communicate final eliminate if appropriate (winnowing)
disposition disposition disposition
R/3 team make final disposition

BW Team to forward completed detailed report specifications

based on selected Reporting Tool - BW or R/3 A4
Baseline reports
LEDGER
D1 Is the documentation complete (Information Request Form)?
D1a - Is this really a reporting need or a "want"? This is determined by looking at the current operation environment and the role
the requestor has in the organization.

D2 - Is the data going to be in BW at a frequency that solves the user's request (intraday reporting)? This is driven by users need as well as technical
feasibility of being able to load the data in a timely manner. In general, intraday reporting may be better suited to come from R/3.
D2.5 - Is the data needed for this report already in our BW scope? If the data is already in-scope, the delivery of the requirement may be easy
("low-hanging fruit).

D3 Are there significant number of users? BW development is easier to cost-justify when a large number of users are involved.

D4 Is the report resource intensive. If the report is often executed against R/3 and have many users. If that is the case, a driver can be to free up
transactional resources by moving the report to BW. (having 40-60% of the CPU resources being used for reporting is not abnormal in a
transaction system).

D5 Does standard R/3 content exists. (Are there already a report available in R/3 )? If content exists, it is an indication that R/3 may be considered.

D6 Does standard BW content exists? If content exists in BW, there is a lower cost of deployment of BW than if custom content has to be
developed.

D7 Is it less expensive to create in R/3. If there are custom formatted reports that are transaction oriented, it may be more cost effective to create it
in R/3.

D8 Is BW cost effective. This is a holistic total cost of ownership analysis that includes licensing costs, development costs, support costs, upgrade
costs and cost of future development. It may also include opportunity costs of not developing the system.