using module wise implementation for BI projects rather than ASAP

[Former Member]

Hi all,

I’ve studied about ASAP methodology in http://scn.sap.com/docs/DOC-48920 but I would like to know about other approaches for managing BI projects. I’ve searched through SCN and many other websites but haven’t found anybody sharing their experience in SAP BI implementation approaches other than ASAP.

What are the advantages/disadvantages of designing cubes/reports/dashboards one module after the other instead of doing the blueprint phase for the whole modules then realization of all the requirements and so on as suggested by ASAP methodology?

I’d appreciate your help as I’ve spent hours searching to find an answer.

[Former Member]

any ideas?

[RafkeMagic]

It's been a very long time since I was on a project that still needed to "begin"... I guess there are pro's and con's to both ways of working. Module approach can have as a pro that you are really focused on that one specific module (and you probably set it up very nicely). A disadvantage is indeed when you come to cross-module stuff... as long as you don't do that "quick & dirty", you should still be ok (but experience learns that by that time the "business" wants results quickly, hence you have to start being dirty).

The big bang approach makes you think (or at least, it should make you think) about the global picture first before actually setting up anything. In this way you'll know which areas will be "cross functional", hence you can anticipate that in the setup. Big con is that the business has to wait a (whole) lot longer on results.

My preferred way is to start with a) business content and b) with (part of) a business that has their stuff together (meaning, the know exactly how things work ànd how they're setup in ECC). It'll give you fast results with "standard" data retrieval.

A lot of projects go into detail way too fast and end up with big setups & a high level of detail which in the end doesn't seem to be all that necessary (as initially thought) and has a major (negative) impact on performance.

[Former Member]

Thanks a lot Raf for taking the time to reply.

The problem is that our customers have had too many developments in the system which makes me wonder if we will be able to use standard contents.

[RafkeMagic]

I understand... nevertheless, it gives you the opportunity to show something in a rather fast way. It also gives the ECC people a better understanding of how the "standard" BW flow works. Afterwards you can "redesign" (/adapt) the data model accordingly, but at least you have a positive start.

I only had the pleasure once to work like this and it worked very well (for myself, for the involved ECC consultants and the end users). In the end the even "dropped" some possible "disasters" from the scope.

[Former Member]

Any more ideas everybody?

I just want to know if in BI projects, there are multiple go lives for different modules or just one for the entire project according to ASAP methodology?

[former_member197660]

Hi Sara

Your question is too generic, nevertheless some facts relating to your questions could be following:

The process mentioned in ASAP methodology is industry standard practices and in general followed in all major project (based on my experience).

Although all project are different and requires different approach but on the high level each project goes through following phases:

Preparation -> Blue Print preparation -> Realisation -> Final Preparation -> Go-live & Support

Can you please elaborate the reason to find an alternate method for project ?

Regards

Ashish

[Former Member]

Hi,

Thank you both.

I know the stages in ASAP methodology but I read somewhere that BI projects are different from SAP ERP. In BI you should have multiple go-lives.

This makes sense because unlike ERP projects where you need to have all modules ready in order to go live, in BI you do not have such a critical dependency so you can begin for instance with SD requirements/reports/dashboards then MM and so on.

But on the other hand, I think doing each module one by one can cause problems as you may have cross functional reports which need the involvement of people from different departments.

I would like to know how SAP BI is being implemented in most big companies. I hope everybody can share their experience with me.

Thanks

[former_member197660]

Hi Sara

It completely depends on user requirements thus it is quite important to know which KPI (key figures) they need for reporting.

This information will be the base to decide which extractors you need and if you can achieve desired reporting using standard extractors or have to develop custom ones.

When we developed our system the users have basic requirement to see Logistics & Financial data in BW so we started by using standard LO extractors & FI extractors and later upon requirement extended to COPA, Project systems etc.

As you already know R/3 is a transactional system thus it has dependencies to various modules but BW is a reporting system thus in general it doesn't have dependencies like you have it in R/3.

Hope it helps !!

Ashish

[Former Member]

Thanks for the quick reply. (I'll assign points when some more experiences are shared by others)

So you first started with Logistics requirements, designed everything in BW, created the reports/dashboards etc. and went live in this module ? then you started finance blueprint ,realization , etc. and went live and then the others.... ?

You did not complete the blueprint phase for all modules, and then start realization for all modules and so on?

[former_member197660]

Hi Sara

After our initial preparation meeting we already had the first impression what kind of data users were looking for (Logistic & Finance data).

So we created two teams who then discussed the details further with relevant Sales & Finance departments to understand the reporting requirements.

After completion of this phase both teams worked in parallel to develop and realize reporting solution in BI for the users.

Understanding/Clarification is more important than points so please do post if things are still not clear 🙂

Ashish

[Former Member]

Thanks a lot Ashish.

what if you had PS and MM modules to work on too ?

Would you start PS and MM after you were done with FI and Logistics ? Or would you do the requirement gathering of all modules and then the realization and going live?

ASAP says that do the blueprint for all modules and then start the realization and set a deadline for the go live of the entire project

Also, assume that there is only one BI team responsible for all modules. In that case , that single team should do each module one after the other or follow ASAP and finish the blueprint for everything and then go to the next phase?

[KodandaPani_KV]

Hi Sara,

Stages in BW project

1 Project Preparation / Requirement Gathering

2 Business Blueprint

3 Realization

4 Final Preparation

5 GO Live & Support

Project Preparation

Project team identified and mobilized

Project standards defined

Project work environment setup

Blueprint

Business processes defined and documented

Business requirements defined

Gap Analysis

Business Blueprint document created and published

Realization

Functional Specification documents, including data mappings and data requirements, created and published

Configuration

Technical Specification documents created and published

Development

Unit Testing

Mock data migration or ETL

Final Preparation

Integration Testing

User Acceptance Testing

End-User Training

Final mock data migration or ETL

Knowledge transfer

Go-Live and Support

Data migration or ETL

Application made available to general end-user population

Post-Implementation (Warranty) Support by development team

Blue Print documents

http://www.sap.com/services/servsuptech/bestpractices/index.epx --- look for blueprint

http://iris.tennessee.edu/Blueprint/BW/BW-Blue%20Print-Final.doc

http://help.sap.com/bp_biv335/BI_EN/html/Business_Blueprint.htm

You can get some detailed information in the following link.

http://sap.ittoolbox.com/documents/document.asp?i=3581

Thanks,

Phani.