Hi Ashfaq,
Quite an open ended question. But here are some generic considerations. Not sure what you mean by all the configured objects. You can use SE80 to check the application component hierarc and decide for yourself what funcitons you will need to implement. In general building a new SCM7.0 (or whatever version) means
I expect other experts to add to this list and let the moderator move this post to wiki on this thread. As such your question is important but answers may vary a lot depending on individual experiences.
- You need to create complete BW workbench objects for basic DP set up. You may note that BW is not multiclient compliant by design. This means if your source system is ECC only then only one client of ECC can be used to transport changes to BW in APO. These BW objects can then be used across clients in APO. So you need to decide the landscape of Dev, QA and prod - whether you want it by client or as separate app servers. This is an important decision within the overall framework of your transport movements and client copy/back up strategy. If this is not sorted out, sort this out first by talking to SAP and BASIS.
-Decision on sizing of APO DB and LC. Take a 15 year view of data build up in APO esp. CVC's, time series horizons, number of possible orders in live cache etc. This may be often ignored as most companies may not have a good archiving strategy in ECC and APO. You dont want to work in a system where it take 5 minutes to load a planning book and 12 hours for a CTM run
- Provision for a full time APO DB and Live Cache administrator. In most companies the ECC BASIS guys are expected to take this role and sometimes they may not be fully aware of admin tasks in APO. So have one BASIS guy trained specifically for this.
-Connecting multiple source systems to APO. or the likelihood of it in future. Note that DP/BW architecture is based on ETL tools whereas SNP and PPDS is integrated to ECC real time. If you have other source systems to to bring data into APO, you need to think of the architecture for integration and data extraction.
-APO BW for reporting ?. it may be tempting to use APO BW for all your analytical reporting needs but you need to think of a long term strategy. The BW in APO is only meant for design of APO DP SNP.
Functional considerations could be several
- A clear startegy on what materials and locations you want to plan in APO. Is there ever a likelihood of using classes and characteristics or variant configuration in APO. This may compound your CVC's. Other things that can compound data is e.g. use of customers as plannable locations in APO
-Heuristis or CTM or Optimizer. You may need to dedicate a separate server for CTM... if you are inclined to using it. Optimizer may also need a separate box. This however depends on the volume of data.
-Integration of other applications to APO. e.g. external applications for forecasting, load building, simulation, optimization etc.
-Planning versions and motivation for having multiple planning versions in APO. Be clear on whether and why you need more than one planning version. These are important initial considerations.
-Interactive or Batch. Depending on the user motivation, you may have an environment that is more interactive or automated. It is possible to run APO like a black box by schediuling all activities in background...using process chains or normal background jobs. Evaluate a high level strategy. The intelligence of users to interpret results is the most important consideration in design.
Guru
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.