Post on 20-Dec-2015
transcript
© 2006 Wellesley Information Services. All rights reserved.
Dr. Bjarne BergLenoir-Rhyne College
Implementing a global Data Warehouse:
Approach, architecture and what you need to know before you start
2
What We’ll Cover…..
• Why build a global BW system?• Designing a global BW architecture• The six dimensions of global BW project management• Global BW project examples
An in-depth look at a global Telecom A global industrial company A glance at four other global BW implementations
• Getting the team together• Lessons learned: global BW project management
Project Management, the team composition, the BW Product and other lessons learned
• Wrap-up
3
What We’ll Cover…
• Why build a global BW system? Business case Scope Approach Performance measures Tool selection
• Designing a global BW architecture• The six dimensions of global BW project management• Global BW project examples• Getting the team together• Lessons learned: global BW project management • Wrap-up
4
Where Does Senior Management Think It Is?
82% of senior executives believe that the information they need to make decisions is available in the company, but very hard to get a hold of.
Source: Forbes Magazine
Why??
5
Why is Management Not Getting What It Wants?
1. Reporting is still organized around departmental functions
2. Reporting is organized around geographical boundaries
3. Tools are not standardized
4. The focus has been on standardizing processes
Most importantly: A global enterprise reporting architecture has not been implemented
82% of senior executives believe that the information they need to make decisions is available in the company, but very hard to get a hold of.
Source: Forbes Magazine, 2003
6
Why Consider a Global Data Warehousing Solution?
“The advantages that data warehousing offers — faster market response, reduced operating costs, knowledge-based strategic decision support, and more — have made it a required tool of the global economy.” Paul Foote in “State of the Marketplace”. Faulkner Information Services
The more access a company has to global information, the faster it can respond to opportunities, threats and risks.
Monthly performance reporting is simply not adequate to run a modern multi-national organization…
Transactions (i.e. R/3)
BI
DW (BW)
Operational Data Store(BW)
Note
7
BI Analytics vs. Reporting
Level of Project Delivered Content
Tools andaccelerators
Industry and process specific solutions
Lev
el o
f E
mb
e dd
ed A
nal
ytic
s
Complex analytics(balanced score-cards, budgeting, planning, KPI)
Interactive Mgmt. reporting
(OLAP, MQE)
Alternative Approached to ERP iAnalytics
ERP Data warehouse(1st generation)
Enhanced data warehouse(2nd generation)
Custom analytics(2nd generation)
Integrated analytics(3rd generation)
Decide early on how
much analytics vs.
basic reporting the team
is going to deliver.
Balanced scorecards
based on key performance
indicators require more
substantial more work
than creating simple
financial reports.
How will users access
data in multiple areas?
BI Analytics contains pre-developed rules to view or examine data
8
What Facts and Activities Drives the Company?
DevelopProducts/Services
PerformProcurement
ProduceProducts/Service
ManageLogistics/
Distribution
PerformMarketing/
Sales
Manage Customer Service
• Research Customer/Market Needs
• Conduct Basic Research• Design & Develop
Products / Services• Test-market Product• Develop Resource
Requirements Plan• Develop & Implement
Manufacturing Processes• Develop & Implement
Service Processes
• Manage Vendor/Contractor Relationships
• Order Materials/Supplies• Manage Inbound Logistics• Receive
Materials/Supplies• Manage Material/Supply
Quality• Manage Raw
Material/Feedstock Inventory
• Return Materials to Vendors
• Qualify & Select Vendors/Contractors
• Manage Engineering Changes
• Manage Product/Service Quality
• Obtain, Install, & Maintain Production Equipment
• Develop & Maintain Production Procedures
• Plan Capacity• Plan Production
Requirements• Schedule Production• Produce & Package
Products/Services• Perform Production
Control• Manage Work-In- Process
Inventory• Develop & Maintain Bills
of Material/Formulae
• Plan Inventory Levels• Manage Finished Goods
Inventory• Manage Outbound Product
Flow• Manage Transportation• Perform Shipping• Manage
Warehouses/Distribution Centers
• Develop Market Strategies• Develop Marketing Plan• Develop Assortment/Brand Plan• Develop Product Packaging• Create Demand Forecast• Establish & Manage Distribution
Channels• Manage Finished Goods
Inventory• Manage In- Store Merchandising• Manage Sales Force/Brokers• Plan & Execute Promotional
Events
• Process Customer Orders• Manage Product
Packaging/Configuration• Manage Product/Service Pricing• Manage Scheduling• Manage Customer Credit
Ratings• Handle Inquiries/Complaints• Collect Customer Data• Provide Customer Service• Handle
Warranties/Claims/Returns
Do not build a global system around what data is easily "available".
STEP 1: Determine what activities in the supply chain drives the profit of your company. Regardless of organizational, geographical or system boundaries.
9
Determine Your Global Performance Measures
• Equipment/Labor (Utilization)• Headcount• Process Steps (Number• Product Development (Cost)• Product Development (Cycle Time)• Product Introduction (Number)• Schedule/Cost Estimates (Accuracy)
• Equipment/Labor (Utilization)• Headcount• Process Steps (Number)• Purchase Discounts (Value)• Purchase Order
(Volume/Frequency)• Purchase Price Variance (Value)• Purchasing (Cost)• Purchasing (Cycle Time)• Supplier Defects (Number)• Supplier Lead Time• Supplier On-time Delivery• Suppliers (Number)
• Changeover/Turnaround (Cycle Time)• Defects/Off-Quality (Cost)• Defects/Off-Quality (Volume/Quantity)• Engineering Design Changes (Cycle Times)• Engineering Design Changes
(Volume/Frequency)• Equipment/Labor (Utilization)• Headcount• Inventory Work In Process (Level/Value)• Manufacturing (Cycle Time)• Parts/Stock Keeping Units (Number)• Process Steps (Number)• Production Lot/Batch Size• Production Schedule (Accuracy/Fulfillment)• Productivity/Throughput• Quality of Service• Rework (Cost)• Rework (Volume/Frequency)• Scheduled Maintenance (Cost)• Scheduled Maintenance (Cycle Time)• Scheduled Maintenance (Frequency)• Scrap/Waste (Cost)• Theft/Shrinkage (Cost)• Unscheduled Maintenance (Cost)• Unscheduled Maintenance (Cycle Time)• Unscheduled Maintenance (Frequency)
Perform ProduceDevelopProducts/Services
STEP 2: Determine what performance measures you need to track in BW. Consider what successful companies in your industry are doing..
10
Distribute Products
Market / Sell Products / Services
Manage Customer Service
Look to the Industry for Best Performance Measure Practices
• Carriers (Number)• Dock-to-Stock (Cycle Time)• Equipment/Labor (Utilization)• Headcount• Inventory (Accuracy)• Inventory Finished Goods (Level/Value)• Inventory Finished Goods (Turnover)• Inventory Intransit (Level/Value)• Inventory Raw Materials (Level/Value)• Inventory Raw Materials (Turnover)• Picking (Accuracy)• Picking/Packing (Cycle Time)• Process Steps (Number)
• Advertising Effectiveness (Awareness)• Advertising Effectiveness (Perception)• Annual Purchase Volume• Closure/Conversion Rate• Customer Complaints (Volume/Frequency)• Customer Retention Rates• Customer Returns (Number)• Design/Formulation/Package Changes
Distribution Channels (Number)• Event ROI• Forecast (Accuracy)• Forecast (Cycle Time)• Headcount• In-Stock Ratio on Promoted
items/Rainchecks• Marketing (Cost)• Marketing (Cycle Time)• Marketing Effectiveness (Cost)• Marketing Effectiveness (Cycle Time)• Product/Brand Forecast (Accuracy)• Product/Brand Forecast (Cycle Time)• Shelf/Floor Allotment• Shopping Frequency• SKU’s (Number)• Traffic Count & Transaction Size• Variance to Plan (Market Share)• Variance to Plan (Production Cost/Volume)• Variance to Plan (Sales Value/Units)
• Adjusted Orders (Volume/Frequency)• Backorders/Stockouts
(Volume/Frequency)• Billing (Cost)• Billing (Cycle Time)• Credit/Debit Memos
(Volume/Frequency)• Customer Satisfaction Rating• Equipment/Labor (Utilization)• Headcount• Inquiries/Complaints
(Volume/Frequency)• On-time Delivery Rate• Order Fill Ratio• Order Fulfillment (Cycle Time)• Order Processing (Cycle Time)• Order Processing (volume)• Process Steps (Number)• Response/Wait Time• Warranties/Claims/Returns (Cost)• Warranties/Claims/Returns
(Volume/Frequency)
NOTE: The performance measures may be different than those you are reporting on today…
Ignore organizational, geographical or system boundaries.
11
Where Are We?
• Why build a global BW system?• Designing a global BW architecture• The six dimensions of global BW project management• Global BW project examples• Getting the team together• Lessons learned: global BW project management • Wrap-up
12
OperationalReporting
More SummarizedMore Ad Hoc
Management InformationLightly Summarized
Real-timeInquiry
Dividing LineDividing Line
ERPERP DWDW
What Logically Belongs in a Global BW System?
Four years ago, with version 3.0B, BW became increasingly able to report on operational detailed data. But some reports still belong in R/3 or other transactions systems…
13
The Global Target Architecture – An Example
Meta Data
Data Warehouse and Decision Support Framework
R/3
LegacySystems
External systems
Internet
Messaging
Source Data
DataExtractionTransform
andLoad
Processes
Extract
Summation
Marketing& Sales
Purchasing
Corporate
Product Line
Location
OperationalData Store
Translate
Attribute
Calculate
Summarize
Synchronize
Transform
SummarizedData
Data Subsetsby Segment
DataWarehouse
OLAP
DataMining
Batch Reporting
Managed Query Env.
Access
Data MartsVendor
Provided
Reconcile
Finance
Supply
14
Approximate Usage of Standard Content BW 3.5 (percentage of overall development effort)
0
20
40
60
80
100
* Rapidly improving content
Where do I start?
All functional areas are not equally supported by strong standard SAP BW business content. Some areas have much you can leverage, others will require significant enhancement to meet your requirements The differences are often due to customization on the R/3-side by companies and/or industry solutions.
Focus on an area that solves a problem instead of becoming a "replacement" project.
Gradually, using a prioritized phased approach, solve other business problems.
A good way to think of a BW rollout is in terms of business problems.
15
Where Are We?
• Why build a global BW system?• Designing a global BW architecture• The six dimensions of global BW project management• Global BW project examples• Getting the team together• Lessons learned: global BW project management • Wrap-up
16
The Six Global Dimensions
There are six core global dimensions you must consider before embarking on a global DW strategy.
Project management is important, but it’s only one of these dimensions. Failure to account for the others may result in project failures.
Source: Peter Grottendieck, Siemens
For each dimension, articulate an approach, constraints, limitations and assumptions before you start your project.
17
The Six Global Dimensions (cont.)
Be aware that US management styles can often come across as very aggressive and authoritative. To get local buy-in, assign meaningful leadership roles to local managers.
Culture, language, attitudes and politics can get in the way of a global project…
Make sure you have a blend of local resources in leadership roles and consider local consultants instead of bringing in US resources…
Intercultural Know How
18
The Six Global Dimensions (cont.)
One of the first steps is to make sure you have reliable connectivity and bandwidth to move the data each night…
What happens if the data movement fails?
How can you get access to backup tapes?
Can the bandwidth handle end-of month high volumes?
What infrastructure do each source site use?
Infrastructure Prerequisites
19
Documentation
The Six Global Dimensions (cont.)
Do all team members and end-users communicate as effective in English?
1. Do we need multi-language training and documentation?
2. Does basic conversational English mean that users can read and understand technical training material and documentation?
3. Have you installed Unicode on your BW system?
Training
20
Plan for solving Global SAP BI project issues
Having IT people engaged in SAP BI global development without providing the right infrastructure, approach and management is a recipe for failure
Source: Leveraging resources in global software development Battin, Crocker, Kreidler, Subramanian, Software, IEEE
21
How Tightly Should Multiple BW Projects be Controlled?
Source: The Conference Board Survey
The relationship between global control and success:
88% Successful88% Successful 30% Successful30% Successful
Loose Cooperation(38%)
Independent(38%)
Tight Central Control(24%)
100% Successful100% Successful
Coordination of Multiple Data Warehouse Projects
22
Six ways to organizing the Global BI development effort
Benefits Risks
1 Single site
2 Distributed analysis
3 Distributed analysis and design
4 Co-located analysis and design
5 Multiple co-located analysis and design
6 Fully distributed development
Option
The more distributed the SAP BI development effort becomes, the more difficult it is to maintain communication and get cohesive requirements.
23
Where Are We?
• Why build a global BW system?• Designing a global BW architecture• The six dimensions of global BW project management• Global BW project examples
An in-depth look at a global Telecom A global industrial company A glance at four other global BW implementations
• Getting the team together• Lessons learned: global BW project management • Wrap-up
24
• Fortune 100 company with operations around the world• 230 systems identified as “mission critical”• 23 installations of SAP R/3 on 6 continents• Other ERP systems:
JD Edwards Custom-developed Oracle systems
Let’s Look at a Global BW Project Example
A case study
25
Data Warehouse Initiatives
These were the DW initiatives that corporate HQ knew about
A case study
26
Alternative Global BW Approaches
CO
NT
INU
E
TOP-DOWN APPROACH
Build a global data warehouse for the company, and proceed sourcing data from old legacy systems driven from a top-down approach.
CH
AN
GE
BOTTOM-UP APPROACH
Focus on a bottom-up approach where the BW project will prioritize supporting and delivering local BW solutions, thereby setting the actual establishment of the global Data Warehouse as secondary, BUT not forgotten.
A case study
27
Bottom-Up Approach Rationale
Improved ProjectManagement
Improved ProjectManagement
Improved CostEfficiency
Improved CostEfficiency
Secured Commonalityacross Company
Secured Commonalityacross Company
Leveraged SAP Decision SupportLeveraged SAP
Decision Support
Minimizes local invest-ments through a consolidated hardware environment.
Leverages buying power in front of vendors through pro-vision of guidelines and corporate agreements.
Enables lower development costs through centralized user documentation and training.
Substantially reduces ABAP report programming costs through providing support for an efficient SAP BW roll-out.
Enables future migration of standardized data architecture to a Global DSS architecture through standard local solutions.
Ensures higher quality of local deliveries and projects through increasing focus on providing local solutions.
Establishes a better working environment between local units and central project management through the positioning as a “Competency Center for Local Needs”.
Ensures use of common definitions.
Ensures uniformity through eliminating options to develop regional, functional or non-standard solutions.
Provides centralized testing of vendor software (combined with ESOE etc).
Using ONE methodology - one way of working.
Ensure reusability.
Reusability will ensure commonality !
Provides users with a fast way to integrate ERP reporting to advanced stan-dardized decision support systems through simplifying the roll-out of SAP BW
Enables the inclusion of future SAP-based standard decision support modules (SEM, EC and others).
Reduces delivery time of decision support for SAP R/3 through usage of a standardized application.
Creates a Competence Center for SAP BW.A case study
28
SAP BW Rollout Approach
• The project delivered local SAP BW solutions and packaged solutions for decision support as a first priority, and the Global Data Warehouse as a second priority.
• A “fixed departure approach” was applied with focus on delivering solutions rather than projects and software; specific BW solutions were developed according to a pre-defined schedule where local business units were invited or encouraged to participate.
CH
AN
GE
CH
AN
GE “Bottom-Up
Fixed Departure”
Departure I - 3 months
Departure II - 3 months
Departure III - 3 months
Departure IV - 3 months
A case study
29
A Global Rollout – a Different European Example
In this case, the company created both a local and global BW system for CRM data
Switzerland
Austria Turkey
Global Development
Spiridon/CRM
others
BW
Belgium
Spain
Portugal
others
CRM (one client)
Ireland
UK
Netherlands
others Local
AMC/Dev
Spiridon/CRM
Local AMC/Dev
Spiridon/CRM
Spiridon CRM
South West (Madrid)
BW
Local AMC/Dev
Spiridon/CRM
Spiridon CRM
North West (Den Haag)
BW
Local AMC/Dev
e.p@ss/CRM
e.p@ss CRM
Mid South (Wien)
BW
Source: Siemens Corp information
30
Some Lessons Learned From Other Global Implementations
The major findings highlight the need for specialized BW skills and very strong scope control…
BW version 3.1c 3.1c 3.0b 3.2
LargestVolume
5-20 milliontransactional records
in FI cubes
Largest cubes have 18.8million, 18.4 million, and
11.2 million recordseach.
35 million rows 120 million records insales, and 230GB inSales and finance
Lessonslearned
Keep scope anddevelopment effortfocused, use more
than onepresentation tool,
don’t underestimatethe extract and load
effort
Should not have gone“live” on 1.2a, shouldhave used more thanone presentation tool.The extract and loadprocess is the mostcomplex, strong BW
experience is essential
Data movement isthe most complexpart of BW. The
project would nothave accepted asmany enhancements
Custom coding cannotovercome the BW
extractors. Integrationwith non-R/3 data was
technically easy, but conceptually hard.
The team members musthave solid BW skills
Businessdrivers
Standardized globalreporting
Creation of corporateenterprise-wide data
warehouse
SAP R/3 was beinginstalled, and SAPBW is the reportingstrategy for all key
performanceindicators
Custom global reportinghas a too-high cost
of ownership and is toohard to manage. Want
content and features.
Success
Very happy withimplementationadded 3 more
countries last year
Overall happy. Haveaccomplished in 6months what wouldhave taken 5 years.
Is being rolled out to more subsidiaries
and management is pleased with results
Very happy with thespeed of delivery and
user satisfaction
Very largeglobal telecom Co.
Global oil co. Global oil co. Fortune-500Retailer
if done again.You need a really .strong BW architect
Note
31
Example Summary
• A conceptual architecture is the first step and the physical architecture is a product of this. It should be driven by the user needs and the types of interfaces needed, and not by an internal IT exercise.
• SAP BW can now be used as an enterprise Data Warehouse and a Global rollout can be accomplished.
• There are two core ways to succeed, but both require strong central control and support.
32
Where Are We?
• Why build a global BW system?• Designing a global BW architecture• The six dimensions of global BW project management• Global BW project examples• Getting the team together• Lessons learned: global BW project management • Wrap-up
33
Practical Tips: Getting The Global Team Together
• Involve relevant business departments, regardless of organizational and geographical boundaries.
Create a user acceptance team with a total of 5-7 members from the various business departments or organizations. Keep the number odd to assist with votes when decisions are made. With fewer than 5 members it can be hard to get enough members present during some meetings.
Make the team the focus of requirements-gathering in the early phase and let this team later become the user acceptance team (testing) in the realization phase.
Meet with the team at least once a month during realization to refine requirements as you are building and have something to show the team.
Issue
This approach is hard to execute when also managing scope, but essential to make sure the system meets the requirements
34
Basis and functional R/3 support
15-25 team members and normally 6-18 months duration depending on scope
P orta l deve loper(s )
B W A rch itec t
B us iness ana lys t/(sub-team lead)B W deve loperP resen ta tion deve loper(s )E T L deve loper
S a les T eam
B us iness ana lys t/(sub-team lead)B W deve loperP resen ta tion deve loper(s )E T L deve loper
F inance T eam
B us iness ana lys t/(sub-team lead)B W deve loperP resen ta tion deve loper(s )E T L deve loper
M ate ria l M gm t. T eam
P ro jec t M anager
P ro jec t sponsor/S tee ring C om ittee
These are roles not positions. (sometimes one team member can fill more than one role)
Tip: Keep back-end developers centralized, while query developers can be de-centralized….
Practical Tips: Getting The Global Team Together (cont.)
35
Sleep, Travel and Time Zones…..
•People crossing 4 or more time zones need over 36 hours to adjust! This increases to over 72 hours when crossing 6 or more time zones. Some simple rules to address this:
Create a "project time" in the middle. I.e. for European and US projects, middle time would be Eastern US time +3 hrs, and European central times less 3 hours. No meetings would be scheduled between 8-11am in Europe, nor between 2-5pm in the US.
Fly to the destination the day before, or allow at least 4 hours downtime for sleeping and showering at the hotel.
Don’t schedule meeting times around when people are traveling. Keep each trip over 5 days minimum to adjust for sleep, or risk running the team "into the
ground"… Plan extended weekends for family time for staff after a long trip (including consultants)…
Source: Leveraging resources in global software development Battin, Crocker, Kreidler, Subramanian, Software, IEEE
36
Effort, Duration and Mistakes on Global BI Projects
Source: “Planning and improving global software development process” by Setamanit, Wakeland, Raffo, May 2006, international workshop on Global software development
Recent research have demonstrated that global projects that spends more days (duration) on similar tasks, have less defects and less re-work.
Since team members are more likely to work on multiple tasks not related to the project, longer durations on developing the SAP BI system does not mean more effort (i.e. work hours).
37
Global Project Risk Mitigation Strategies
L - Limitations (what are the assumed, existing and design limitations)
A - Assumptions (what assumptions are made, and what happens when these assumptions are no longer true?)
R - Risks (what are the risks created by this approach, what are the impacts of failure, and how can these risks be minimized)
Developers, designers and business analysts should be forced to write at least one paragraph on each of these item.
It forces new thinking as well as the constant questioning of assumptions (which may not be accurate).
State 3 items in every design, budget and final deliverable:
38
Global Project Risk Mitigation Strategies
Add 15% more project time for travel and adjustments
Rotate travel so that the stress is more evenly distributed on the team
Plan to spend 5-10 days at the beginning of the project to level set and build trust and social networks before the real work begins.
Create a formal escalation process of issues related to the project and make sure one culture does not dominate.
Select a project language formally and make sure all team members are proficient in it.
Spend time rewarding inter-team cooperation and create opportunities for promotion within and outside both teams (“cross pollinate”)
39
The Use of Local “Ambassadors”
Getting power users involved early is important to the overall success of a Data Warehousing project.
To help support the businesses that have already gone live, a strong local community of “ambassadors” is needed.
If you don’t have them, on-going projects may get “bogged down” with basic support of reports.
40
Where Are We?
• Why build a global BW system?• Designing a global BW architecture• The six dimensions of global BW project management• Global BW project examples• Getting the team together• Lessons learned: global BW project management
Project management Team composition BW Product Other lessons
• Wrap-up
41
Lessons Learned: Global Project Management
• A user acceptance team (UAT) of 5-7 people should be created from the first day, and all acceptance criteria should be established well in advance of the implementation
• Use of Rapid Application Development is the preferred development methodology
• Use a phased business content approach with standard delivered content first, then customize if absolutely needed
• It is hard to estimate accurately the data movement effort — 80% of delays and surprises occur in this area, and this work is often under-estimated
• Treat the workplan only as a tool and adjust it as needed
• Spend less time on the project preparation phase and as much as possible on the realization phase. Many issues cannot be planned, but time can be set aside to deal with them.
42
Lessons Learned: Team Composition
• Developer training should start early for all project team members
• SAP R/3 skills are not easily transferable to BW — hands-on experience is needed (it’s hard to learn while being productive)
• The quality of the team members is much more important than the number of members. A skilled BW developer can accomplish in one day what 3 novice developers can do in a week.
• Project time and cost estimates should be based on teams’ experience levels
• Plan on formal knowledge transfer from external resources starting from day one. Link inexperienced members with experienced ones
• Have identified “go-to” resources available in all areas (make a list)
43
Lessons Learned: The BW Product
• The time to develop BW will depend on how much customization was done when R/3 was installed
• The tool has a high learning curve and training cannot substitute for experience.
• Plan on spending 10-15% of overall effort on performance tuning of queries and data loads. Test the performance as part of the development effort.
• Implementation of LIS, SIS, EIS are no longer needed to use most standard extractors from BW, but most extractors are normally enhanced. Plan on using 50-60% of the project effort on data extraction, movement, validation, load, scheduling and testing.
44
• Use the statistics cube to monitor system performance and don’t forget to use the cost-based optimizer if you are using Oracle as your database
• Direct updates to InfoCubes (non-loads) are complex. If this is needed for reconciliation efforts, create a data staging area, make changes here and re-load the data. Direct cube updates for non SEM/ APO, SCEM cubes are hard to make work in practice.
• Do not succumb to using BW as a dumping ground - some reports belongs in R/3.
Lessons Learned: The BW Product (cont.)
Finally, do not attempt to “cram” all data into one cube. Keep InfoCubes logically organized and use multi-providers as needed.
45
Other Lessons Learned
• Global user training should be custom-made and tailored to each country or region, and delivered by a local resource.
• A global line support organization should be established and be part of the development effort (knowledge transfer).
• Buy hardware early (international delivery times can delay the project)
• Locate the users as soon as possible and take a look at the network
• Finally, create “Ambassadors”, “road shows” and/or “brown-bag” sessions.
46
Where Are We?
• Why build a global BW system?• Designing a global BW architecture• The six dimensions of global BW project management• Global BW project examples• Getting the team together• Lessons learned: global BW project management • Wrap-up
47
Resources
• Global Project Management Handbook by David L. Cleland, Roland Gareis. Hardcover: 672 pages. McGraw-Hill Professional; ISBN: 0070113297
• International Journal Of Project Management, Magazine Publisher: Elsevier Ltd ASIN: B00007AYDS
• The Distance Manager: A Hands On Guide to Managing Off-Site Employees and Virtual Teams by Kimball Fisher, Mareen Fisher. Hardcover: 252 pages Publisher: McGraw-Hill; ISBN: 0071360654
48
7 Key Points to Take Home
• Use the 6 global dimensions framework to guide your BW development
• Plan for a truly Enterprise Architecture that is designed, not evolved
• Spend much time on getting the right resources on your team
• Involve the local staff in a proactive manner and make them part of your leadership team.
• Don’t re-invent the wheel — use experienced resources that have done it before and pay particular attention to management styles, politics and culture.
• Conduct post-implementation reviews with each local organization in order to learn from experience and to give the subsidiaries a voice in how the project is executed.
• Consider an "ambassador" concept to assist in local support and buy-in.
49
Your Turn!!!
How to contact me:Bberg@MyITgroup.com