1. Six Reasons Why Customers Chose BC Sets for Global Rollouts
Marc Oliver Schaefer SAP AG

2. Learning Objectives As a result of this workshop, you will be able to:
To explain how BC Sets can support your global rollout
To understand how BC Set pilots used this technology
To explain what BC Sets are and how you benefit from them

3. You need 4.6c! Agenda Reason 1: Evolution
Reason 2: Business process orientation
Reason 3: Transparency
Reason 4: Protection
Reason 5: Re-use
Reason 6: Flexibility
Lessons learned
You need 4.6c!

4. The Traditional Approach - Outline
IMG activities which contain global customizing are tagged
All IMG activities containing global customizing are combined in a project IMG
Written documentation about the status of the settings is added to the IMG activities
Global customizing values, IMG tags, project IMG and documentation are transported to the subsidiaries and implemented
Documentation
Documentation
Smallest unit in IMG is the activity
Smallest unit inside an activity is a table row
No customizing is locked
A lot of written information
Transported to subsidiaries

5. Evolution

6. Evolution
Customers often see a global roll-out as an extension of an existing installation
One pilot customer wanted to use existing UK client as basis for a template
Customers want to re-use existing customizing
Which is in the system
Which is stored in transports
Customers want to develop version 2 of their template out of version 1
Version 1 should be adapted, not overwritten
No problem with traditional approach
No problem with traditional approach
Difficult with traditional approach
BC Sets allow you to move customizing from one system to another
BC Sets can be created from transport requests
You can have multiple versions of customizing with BC Sets

7. Business Process Orientation

8. Business Process Orientation
Customers often think in terms of business processes, but customizing is structured by applications (SD, MM, HR ...)
Customers want to pre-configure processes centrally and leave only little room for local adaptions
Reduction of customizing complexity for local implementations teams (iceberg principle)
Difficult with traditional approach
Very difficult with traditional approach
BC Sets allow you to
take customizing from anywhere in the IMG
structure customizing according to business processes
hide those parts of customizing which are not of interest to local teams

9. BC Set for Milestone Billing
Payment due on 00/05/03
Payment due on 00/05/13
Payment due on 00/05/23
Business functionality to be
performed by the SAP System...
Bill
...and its Customizing
representation

10. BC Set for Milestone Billing
Customizing representation
BC Set
• IMG Activities
• Customizing Settings
• Attributes
Milestone Billing
Copy

11. BC Set for Milestone Billing
Payment due on 00/05/03
Payment due on 00/05/13
Payment due on 00/05/23
Bill
Business functionality to be
performed by the SAP System...
... and its Customizing representation
BC Set
• IMG Activities
• Customizing Settings
• Attributes
Milestone Billing

12. Transparency

13. Transparency
Customers want to define precisely what belongs to their template
Customers want to define for each customizing value whether it can be overwritten
Customer want to know exactly which settings belonged to which template release
Difficult with traditional approach
Very difficult with traditional approach
Very difficult with traditional approach
BC Sets allow you to
define global customizing on value level
define which settings may be overwritten and which not
keep all versions of your template simultaneously in your system

14. BC Set Content BC Set Traditional approach Table 1 Table 2
Milestone Billing
Table 2
• IMG Activities
• Customizing Settings
• Attributes
Table 3
Table 4

15. Protection

16. Protection Customers want to protect global settings against changes
Customers want to preview customizing before import
Impossible with traditional approach
Impossible with traditional approach
BC Sets
allow you to lock 60-80% of customizing
can be imported without changing the existing customizing

17. Customizing import
Using transports
1 Step
Using BC Sets
2 Steps

18. Re-use

19. Re-use Customers want to re-use existing customizing in their template
Customers want to encapsulate and distribute „golden config“
Customers want to quickly apply their „golden config“ in the local systems
Customers want to base version 2 on version 1
No problem with traditional approach, but ...
No problem with traditional approach, but ...
No problem with traditional approach, but more elegant with BC Sets
Difficult with traditional approach
BC Sets
re-use customizing from transport requests
re-use customizing from one or more existing clients
can be duplicated and refreshed
are distributed with the transport system
can be uploaded and downloaded
can be activated in the subsidiary systems

20. Re-use of customizing Subsidiary 1 Subsidiary 2 Process 1 Headquarters

21. Managing Customizing Template Versions
Process 1 BC Set Version 1
Process 1
BC Set Version 2
Copy and refresh
Process 1
BC Set Version 3
Copy and refresh
Only one version can be active in the customizing tables

22. Flexibility

23. Flexibility
Customers want to apply customizing flexibly, e.g. org units
Customers want to reduce the amount of customizing that surfaces during the implementation of a template
Customers want to be able to quickly deploy template patches
Impossible with traditional approach
Impossible with traditional approach
No problem with traditional approach
BC Sets
allow you to re-use customizing flexibly (with respect to org units)
allow you to reduce the complexity of customizing during implementation
can be downloaded, distributed via mail and uploaded

24. Variable re-use of customizing with BC Sets
Flexible Re-use
Subsidiary x
Headquarters
Process 1 (for org unit 2)
Process 1 (for org unit 1)
Process 1 (for org unit 3)
Process 2 (for org unit 2)
Process 2 (for org unit 1)
Process 2 (for org unit 3)
Process 3 (for org unit 1)
Process 3 (for org unit 3)
Process 3 (for org unit 2)
Variable re-use of customizing with BC Sets

25. Reduction of Complexity
Headquarters
Subsidiary x
Implementation
Process 1
Visible
Process 1
Visible
Process 2
Visible
Process 2
Visible
Process 3
Visible
Process 3
Visible
You define in a BC Set ...
what you see during implementation...
... but you get the whole BC Set in the target system.

26. Lessons Learned

27. Pilot Company Profiles
Continental Helium LTD.
Continental Helium
UK based, global company
Products and services focusing on industrial gases
Annual turnover (2001): app. £ 4.000m
Operating profit: app. £ 600m.
More than 43,000 employees
7,500 orders, 5,000 deliveries, 1,200,000 SAP hits every day on a 24 x 7 basis
Chempro
Dutch-based, global company
Life science products, performance materials, polymers, industrial chemicals
Annual sales: app. EUR 8 billion
About 22,000 employees
More than 200 sites worldwide
19 SAP R/3 installations (4,000 users)
15 legacy installations
80% of Chempro‘s SAP systems are on 3.1I, 20% on 4.6c
Company names changed
Success stories are underway

28. Global rollout – Central System Approach
Global Development/
Client Independent Cust.
Local
System Landscape
Country 3 - Development
Template Development
Country 2 - Development
Country 1 - Development
BC Set
Activation
Clients
Central Development
System

29. Lessons Learned (1 of 3)
Finish your customizing before creating BC Sets.
Reserve a phase for creating BC Sets in your project plan.
Small is beautiful: BC Sets should not contain data from different activities.
Use hierarchical BC Sets.
Prepare your customizers for changes. Transport size has to be kept down if small BC Sets are to be created.
Establish clear creation rules before creating BC Sets .

30. Lessons learned (2 of 3)
Don’t use BC Sets if your basis support package level is below 19 (or even 22).
Always apply the highest basis support package available.
You CANNOT put master data, transaction data, reports, etc. into BC Sets
Not all IMG activities can be used with BC Sets – use the IMG analysis reports before creating BC Sets

31. Lessons Learned (3 of 3)
Train the local teams to ensure that the recipients know
What a BC Set is
How to compare BC Sets using the Customizing Cross-System Viewer
How to interpret the results of a comparison
What to do if template violations occur
If activation is to be used, the local teams need to know
How the activation functionality works
How variable fields are handled during activation
How to analyze the activation log
What to do if activation errors occur.

32. Summary Pros Successful pilot projects
Comment
Successful pilot projects
Success stories underway
Flexible and fast creation of subsidiary clients
Pilot: „3 days vs. 6 weeks“
Business process orientation of customizing
Clear definition of what belongs to the template
Less written documentation
Locking of customizing against changes
Works only for 60-80% of IMG, but locking is not possible with the traditional approach. In addition, you can periodically check template compliance.
Easy re-use of existing customizing

33. Summary
Cons
Comment
More effort during initial template development
Subsequent releases of template can be created faster. Template version handling without BC Sets is very difficult.
Pilot: „250 BC Sets covering approx. 2,000 IMG activities in 2 weeks”
Additional Knowledge Transfer
Pilot: „Restrict BC Set creation, testing and application to a small team of experts“
Knowledge transfer is the key, because BC Set knowledge is not yet widespread.
We will use BC Sets again!
BC Sets are a great technology, but it has some sharp edges.
Quotes from BC Set pilots

34. Further Information SAP Professional Journal: Service Marketplace:è
SAP Professional Journal:
è Customizing è
Service Marketplace:

35. Copyright 2002 SAP AG. All Rights Reserved
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.
IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.
ORACLE® is a registered trademark of ORACLE Corporation.
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.
Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
JAVA® is a registered trademark of Sun Microsystems, Inc.
JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.
SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are trademarks of their respective companies.

36. Copyright 2002 SAP AG. Alle Rechte vorbehalten
Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden.
Die von SAP AG oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch anderer Softwarehersteller enthalten.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® und SQL Server® sind eingetragene Marken der Microsoft Corporation.
IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix und Informix® Dynamic ServerTM sind Marken der IBM Corporation in den USA und/oder anderen Ländern.
ORACLE® ist eine eingetragene Marke der ORACLE Corporation.
UNIX®, X/Open®, OSF/1® und Motif® sind eingetragene Marken der Open Group.
Citrix®, das Citrix-Logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® und andere hier erwähnte Namen von Citrix-Produkten sind Marken von Citrix Systems, Inc.
HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
JAVA® ist eine eingetragene Marke der Sun Microsystems, Inc.
JAVASCRIPT® ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von Netscape entwickelten und implementierten Technologie.
MarketSet und Enterprise Buyer sind gemeinsame Marken von SAP AG und Commerce One.
SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com und weitere im Text erwähnte SAP-Produkte und -Dienst-leistungen sowie die entsprechenden Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und anderen Ländern weltweit. Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen.