patrick.rayes

    6 Posts
    Many will argue, as "many" have in the past, that an organization's SAP Center of Excellence (CoE) comes in a variety of shapes and forms; albeit the conclusive and repetitive material in the "SAP Ecosystem" that clearly defines how an SAP CoE should be shaped and what business services it is meant to provide.

    So why the confusion? Reality, in today's economic struggles that organization's face, often shapes a CoE to be driven by operational goals serving to support the company "infrastructure" while being led by the strategy and vision "baked into" the organization by line of business (LoB) stakeholders that know and understand the business needs, processes, short/long term goals etc. Similar to a horse-before-carriage arrangement, if you will, where the organization "owns and drives" the "competency and excellence" of the SAP implementation, and the CoE serves those needs operationally.

    Nonetheless, establishing a SAP CoE that serves the needs of the business, either operationally or both operationally and strategically, requires a set of key processes and tools to get up and running; delivering the results expected by the community it serves. For the sake of this article, we shall assume the establishment of a SAP CoE that not only runs a "help desk"-like service managing tickets/issues logged by the user community, but also integrates itself deeply in the organization to deliver similar value as a mature Enterprise Architecture team. Specifically, and just to name a few, the CoE is to establish and drive the following services:

    - Ability to clearly map out and drive as-is and to-be models satisfying all SAP transformation projects
    - Act as a central point of contact with SAP and related vendors
    - Act as a key integration point in the organization between all divisions and departments, including IT; creation and support of LoB "partnerships"
    - Control the funding and budgeting of all SAP-related projects
    - Define the overall vision of your SAP implementation in close collaboration with key business stakeholders
    - Demonstrate knowledge and ownership of the system (process and technology-wise)
    - Enable an organization to realize its vision through the execution of its mission
    - Establish standards and processes that maintain internal alignment within the CoE and externally with business owners
    - Guide changes to the structure of the organization, and the actions incurred by LoBs
    - Manage all SAP-related projects under one SAP Program
    - Own and drive all system changes (small and large)
    - Provide business process expertise and management
    - Provide governance across data, processes, change management, architecture etc., controlled by known methodologies and frameworks (e.g. SAP EAF)
    - Support development and training services for the user community; develop user skills

    Shaping your CoE requires a set of processes and tools in place to facilitate a stable establishment and consistent growth to satisfy the needs of the business with operational excellence. Below is a list of some of the many to consider:

    Business Process Monitoring
    Invest the time to establish and operate BPM, including NetWeaver PI monitoring; your team needs visibility on the health of system to demonstrate pro-active behavior with the user community. Otherwise, you should expect a barrage of help desk calls when anything fails without your knowledge.

    Business and System Calendar
    Own and publicize an accurate business process and system change/management calendar; keep your community aware of key dates for critical business processes to engage, and when system changes and management activities are performed, and furthermore what each even implies.

    Champion/Expert Users
    Your first line of defense in the user community. A group of users that have gained incremental experience in using SAP during its initial roll-out and have significant influence in an organization's business processes. They are the front-line to addressing issues with the user community, and the extended support network and business process facilitators for SAP.

    Communication Tools
    Invest in tools like Skype, Messenger, Adobe Acrobat Connect, WebEx etc. to allow your user community to easily and effectively keep in touch with your team. A sense of closeness in a global model is crucial to maintaining accountability, trust and open communication.

    Documentation
    From training manuals, to user guides and business process documents, keep everything central, constantly updated and communicated to your user community.

    Integration Management
    Much like in your SAP implementation project, you will need to either nominate a resource in your team, and position a dedicated resource, to support the integration needs of all "process streams" (i.e. FI, SD, MM, CRM, BI etc.). More importantly, during the lifespan of the SAP implementation project team, it is critical that your CoE is well integrated with them to share accurate and transparent information to secure alignment and congruent change management across processes, developments, customizations etc.

    Key Performance Indicators (KPIs)
    Get your KPIs in place as quickly as possible. Measure your performance on ticket resolution, system changes and enhancements, effectiveness of project planning etc. Make this information transparent and visible to demonstrate to your user community that, very simply, "you care".

    Operating Procedures
    Invest initially in actions to define and produce operational procedures that clearly define the daily/weekly/monthly activities of your team across all areas of service (e.g. data correction procedures, business process monitoring procedures, change management procedures etc.).

    Organization Structure
    Usually the first thing to consider, and often the most challenging, when you have to consider what is best for the organization and how to fill positions with strongly qualified staff. Consider the following key factors to consider when placing staff in your team with the qualified expertise and skills:

    - Business skills to deliver on business needs, and organization processes
    - Analytic skills to deliver on business needs, and process changes
    - IT skills to deliver on governance/administration, tools, infrastructure, application and data requirements

    On a related subject, how your SAP CoE is organized in the overall company can be challenging. Some "food for thought" is to have your SAP CoE report initially in the SAP implementation project team so as to get itself well grounded, followed by reporting into the senior manager accountable for the overall project (e.g. CEO, CFO etc.) once the CoE has reached a level of sustainable maturity. Alternatively, distributed or virtual models can work depending on how strong skill-sets you can resource from your organization's current workforce.

    Service Desk
    Centralize your service desk operation so it is controlled by a staff internal to your team. Everything should be logged and managed centrally, and proper knowledge on how to level and assign tickets should be known as well as turning on your computer.

    Solution Manager
    Usually a no-brainer, but often overlooked. Leverage SolMan for all your ALM and help-desk requirements, and get your staff well trained to operate it effectively and efficiently.

    Templates
    Get your templates in place to easily and effectively leverage for producing functional and technical specifications, project plans, change requests etc.

    Vendor Relations
    Establish processes and communication tools to maintain a healthy and productive relationship with your support/help-desk vendor, including SAP as your system vendor.

    As a precautionary note, and last topic to this article, below is a list of key inhibitors to look out for that could cripple the success of your SAP CoE:

    - Consistent failure to deliver excellence and quality to your user community
    - Excessive amount of rudimentary tools (e.g. rampant Excel spreadsheets)
    - Exponential growth of issues and requests from the business
    - Inability to be flexible and stabilize and changing business processes
    - Lacking knowledge of all end-to-end business processes
    - Lacking active and regular engagement with your user community
    - Lacking visibility on internal progress and performance (i.e. no KPIs)
    - Limited and reduced knowledge and skills within your team
    - Limited and eroding sponsorship from key business stakeholders
    - Silo-based thinking and operation

    In summary, a SAP CoE is not just about processes and technology, but it is also concretely about people and serving the challenges and needs of your extended SAP community (inside and outside the organization). Consider these recommendations in shaping your SAP CoE, and with the right attitude and will it should be done. Lastly, bear in mind that this article is not meant to serve as a guaranteed and structured framework/methodology to establish and operate a successful SAP CoE, however to strongly encourage congruent and correct thinking towards a working model that delivers operational excellence.
    When it comes to system integration, Electronic Data Interchange (EDI), interfaces etc., the weight mostly lies with the architecture and technology supported by any of the systems communicating with each other; particularly with interfacing SAP to banks at a global level for processing bank payments and statements electronically. The design, to support scalability and alignment with future electronic banking standards, and the varying technologies used by banks, are often key drivers for such implementations. Now that we have accepted the enormous challenge involved, where does one start?

    Below is a summary of some key areas to focus on during the blueprint and realization phase of implementing bank interfaces between SAP and internal/external electronic banking systems.

    Architecture

    Solution and Technical Architecture, taken through iterative phases, and validation across all stakeholders (often including the business/customer and the bank), is an exercise to not underestimate. I would in fact strongly encourage utilizing the SAP EAF methodology, or at the very least TOGAF, to get through this exercise successfully and produce the relevant planning and architecture artifacts.

    At a more granular level, and this is usually the more exhaustive part of the exercise, take attention to work closely with technical experts from the bank and your ABAP developers to document the details behind each connection point (e.g. field mappings, file formats, transport mediums etc.). Having a comprehensive set of architecture diagrams, matrices and catalogs, that is "signed off" by your development team, the bank and the business (i.e. Finance/Treasury Departments), is a necessary exercise to establish clear understanding and confidence in the implementation.

    Bank Directory

    Configuring SAP with all your bank accounts, bank addresses, bank codes, branch codes etc. can be a long and exhaustive process, particularly when you need to validate every entry with the bank, and often times smaller banks in remote locations will have difficulty in providing this data accurately.

    The satisfactory approach for this effort is to manage this information in a central database/file (e.g. MS Access or Excel), and purchase bank directory software to cross-check against and extract valid information from. Dedicating someone from your finance department to complete this exercise is often good practice, as they will likely have a relationship established with the banks and their respective account managers to streamline and expedite the process. Your technical team will also have to work very closely with your finance department resource and the bank to articulate the context/meaning of the relevant SAP fields that need to be collected (i.e. field lengths, descriptions, uses etc.).

    Bank Software

    Prior to your SAP implementation, it is very likely that you will come across bank software already being used by the A/P and A/R teams in your finance department. For example, Citibank's CitiDirect online tool, or RBC's AP Link software. Often times these client-based software tools will provide payment upload and statement download functionality via electronic methods. They would have already been setup with secured connections to their respective banks, and the end-users would most likely be familiar with the accepted file formats/structures. Involving these end-users at an early stage in the design is beneficial to validating field mappings, file formats, usability etc.

    The complexity around this area is whether post-SAP you continue to use these tools simply as a file transport medium (i.e. SAP produces the outbound payment file, and the bank software automatically/manually uploads the file to the bank). This decision usually hinges on the level of automation needed, cost and time. Ideally, a fully integrated and automated solution via SFTP, direct connection or other means are preferred, however technical feasibility within your landscape can also be a challenge (i.e. security, network constraints etc.).

    Field Mappings

    Whether you go with SWIFT or EDIFACT or XML, you will need to invest a significant amount of time in mapping the fields of these standard banking files to the SAP IDOC fields accordingly. This exercise involves very close participation with the technical team at the bank, online resources (i.e. UN/EDIFACT standards/conventions) and mapping/modeling software.

    More preferably, implementing Seeburger's Cross Industry Adapter can help in minimizing the workload here, as it provides template mappings and tools to conduct the mapping exercise more effectively. Close to a necessary piece of software, one can argue.

    Monitoring

    When it comes to monitoring inbound/outbound bank interface files, mastering the IDOC monitor (e.g. WE05) and PI Workbench might not be enough. Satisfying the real-time proactive behavior of your end-users will require something more usable, providing the necessary information to diagnose and resolve issues effectively. Navigating a wide variety of monitoring tools, one that comes as a preference is the Advantco PI Monitoring tool.

    Project Management

    Instituting some basic project management techniques, even Agile Management, is crucial during every phase of such an implementation. Consider using tools such as a regularly tracked and monitored issue list, weekly or bi-weekly status calls with all key stakeholders (i.e. bank, developers, business users, functional resources, IT department etc.). Keeping a steady pace, and closely monitoring every open technical issue is crucial.

    EDIFACT vs. SWIFT vs. XML

    Cost is a key consideration when it comes to selecting your bank interface standard; you could be looking at development and licensing costs varying on the order of 2-3 times and sometimes even 10 times more depending on the volume of bank payments and statements moving across your interfaces. The number of banks you interface to is also a key cost consideration; particularly when banks can be technologically challenging to interface with (e.g. banks in more remote locations that do not adhere to common standards practiced in North America or Europe).

    From a technology perspective, SWIFT is the most ideal and effective technology to leverage as it is a more unified/centralized model for most banks, whereas XML and EDIFACT fall in second and third place. From a cost factor, you can expect the same order of each technology from most to least cost.

    Transaction Codes

    No, not SAP transaction codes... Bank transaction codes for every transaction line in your bank statement. More specifically, every bank has a set of credit/debit codes they use to identify a transaction (e.g. XC05 for Bank Clearing Fee etc.). Ok, so what's the complexity here? Very simply, and shockingly, you will be looking at 100s upon 100s of transaction codes per bank to configure accordingly in SAP and map to their respective Clearing/GL account.

    There is a sign of relief however, in that most of these codes can be defaulted to a set of accounts in SAP accordingly; this all depends on how your finance department prefers to configure them in SAP and what level of financial granularity you can compromise on. Again, maintaining a centrally managed list of these codes per bank in Excel is key; keep it aligned amongst everyone involved and updated as banks might change these codes over time.

    Alternatively, and with respect to SAP transaction codes, part of conducting the end-to-end design, including business processes involved (for those fellow BPX'ers), consider the accounting transactions necessary pre/post the input/output of these electronic banking files (e.g. FB05, FEBAN etc.). Particularly key when conducting your integration testing.

    Transport Medium

    Several choices exist for transport mediums: Secure FTP (SFTP), Value Added Network (VAN), Odette FTP (OFTP), HTTPS etc.

    Typically, this does come down to a cost and time factor; using one from the other can cost more or less depending on data volume, and can also be more/less complex to implement within your project time line.

    Technologically, VAN, OFTP and SFTP are preferable due to their more wide support by banks. Implementing the right transport tool/software can also be an important decision; from the SFTP standpoint, one that comes as a preference is the Advantco SFTP Adapter tool.

    In summary, effective planning, coordination with the bank technical team, concise and complete architecture and technology selection are some of the key ingredients to an effective implementation of SAP bank interfaces.

    Supplemental to this is an interesting tool from SAP that supports a gamut of electronic banking features that might satisfy the needs of your project.
    Designing, planning and executing the delivery of a SAP infrastructure from scratch can be a daunting task; resembling the coordination and planning of a highly complex and elaborate circus. This article demonstrates some key areas to consider, and how to maneuver in each successfully, so as to produce a sound and executable infrastructure design that will make any circus conductor proud. Bear in mind that this success is also highly dependent on the ideal blend of subject matter experts, business stakeholders and technical architecture resources, combined with some good old common sense and creative thinking!

    Hardware

    As conveyed in a recent What is the best SAP hardware platform and why aren't you on it?, selecting the right hardware comes down to:

    > Mission Critical
    Realistically, how mission critical is your SAP implementation? Do you have a consensus between the business, vendors and IT on this topic? Meticulously analyzing the needs of your end user landscape, combined with some measurements on usage hours, number of transactions etc., and some preliminary feedback from your Right-Sizing Your Hardware exercise, will significantly support your decision on how extensive your Disaster Recovery, High Availability and Resiliency planning should be.

    > Windows vs. UNIX
    A classic and long-time point of contention between competing Operating System "camps" is which OS to use... Drawing from some common sense, and generally known facts about the industry, Sun/IBM/HP UNIX systems have often been leveraged for highly scalable instances, whereas Windows systems for much lower scale systems. Referencing some points from the aforementioned article, UNIX systems scale to about 200,000 SAPS (enough for approximately 40,000 concurrent SD users), and Windows systems scale to 60,000 SAPS (enough for approximately 10,000 concurrent SD users). Some other important factors to consider are: internal expertise/competency, operating system and database strategies, SLAs with the business etc.

    > Virtualization
    A very interesting and exciting topic in the SAP space as of the past 2-3 years, and one to seriously consider as of late with the growing business adoption rates and proven case studies. Going with VMWare has significant benefits that the industry has already taken advantage of for various solutions. As of late, SAP has backed their support of VMWare and selecting this option for your implementation should be openly discussed and seriously considered. An added benefit of leveraging VMWare is to provide VMWare View (VDI) for users outside of your network that have no VPN access and require access to a ready-to-run desktop environment with the SAP GUI installed. Going with mixed landscapes of virtualized Dev/QA environments, and physical hardware for your Production environment, can be an option; however consider the challenges of replicating OS/DB configurations/settings/etc. across each landscape effectively, "snapshots" of servers, and the increased support/costs incurred with physical equipment.

    Databases

    As of late, with the acquisition of Sybase, database selection can be a touchy subject. Given the market forces that SAP has nurtured through their partnerships and database strategy with Sybase, products such as Oracle can be a tough sell.

    Database selections comes down to some key variables including:

    > Internal Competency: does your IT staff, and in particular Database Architect, possess the knowledge and experience to support the database of choice
    > Alignment with SAP Strategy: considering the recent acquisition of Sybase and the push for in-memory databases
    > Findings and Requirements from your SAP Sizing Effort
    > Licensing Costs

    Identity Management and Single Sign-On

    SAP IDM / CUA (Identity Management and Central User Administration) is the standard platform for managing SAP security and the administration of user accounts for SAP back-end systems (ECC and BI). IDM provisions user accounts and authorization access to the SAP back-end systems (ECC and BI). Security Administrators can manage SAP role assignments centrally through IDM; implementing and supporting IDM depends primarily on the following factors:

    > Aligning the IDM implementation with key business drivers and organizational objectives
    > Creating a Governance and Support Model that aligns smoothly with existing organizations and processes
    > Achieving and sustaining high quality identity data as the foundation of the IAM solution
    > Integrating with an organization's existing technology infrastructure and adapting to changes over time

    Monitoring

    In the "monitoring space", there are several options, all of which enrich and expand the basic monitoring services provided by Solution Manager (listed below):

    > Integrated SAP product
    > Manage all systems centrally
    > Preconfigured view and logical collection of administration tasks
    > Daily system administration and monitoring (automatic and manual)
    > Daily/weekly/monthly reporting through Early Watch
    > Monitor SAP and non-SAP Systems

    One such options is Tidal Horizon which compliments the performance monitoring capabilities of SAP Solution Manager by providing out-of-the-box best practices and procedures for automating the analysis and management of SAP operations.

    > Automate complex and routine tasks
    > Optimize resources required for system-sustaining efforts
    > Reduce the complexity of managing a large SAP installation
    > Automatically collect and organize detailed performance data
    > Proactive action basis staff and other high value added resources
    > Consistent analysis of problems in real-time using best practices across the entire SAP infrastructure
    > Traceability of all problems to the technical layer in which they occurred (J2EE layer, ABAP layer, database layer, or network / OS layer)

    Tidal Horizon is an ideal solution for Windows-based platforms as it is an add-on product for Microsoft Operations Manager Server (MOM) that provides rich, deep, scalable operations for SAP.

    Furthermore, SAPs Computing Center Management System (CCMS) allows you to monitor, control, and configure your SAP System. CCMS provides some basic functionality that can be supplemental to a tool such as Tidal, some of which are listed below:

    > Starting and stopping SAP services
    > Unattended 24 hour system management using instances and operation modes
    > System monitoring and automatic reporting of alerts
    > Processing and controlling background jobs, scheduling database backups

    Sizing

    One of the most important exercises to conduct during the early stages in planning your SAP deployment, and one that is NOT to be underestimated. Usually, the classic/quick SAP Sizing exercise can be sufficient (especially if it is done right), yet in some instances requires some intelligent usage of the tool and extrapolating more significant information from it in very close collaboration with your hardware vendor.

    Summarized below are the two types of sizing exercises you will likely engage in:

    > Formal Sizing (Quick Sizing)
    - Breakdown of the number of users by application module
    - Determination of user type – high, medium or low volume users
    - Transaction volume by process area
    - Customization (custom programs)
    - End-user delivery methods (SAP GUI, Web GUI or Portal)
    - Number of interfaces, volume and frequency
    - Batch processes and frequency
    - Printing and reporting
    - High availability
    - Data retention
    - Archiving

    > Informal Sizing (best practices rule of thumb, benchmarked against similar SAP projects)
    - SAP application modules to be deployed
    - Number of licensed users
    - Deployment method (single global instance or distributed)
    - Percentage of custom programs
    - End-user delivery methods (SAPGUI, WebGUI or Portal)
    - Batch processes and interfaces
    - The type of infrastructure to be deployed to support the application
    - High availability
    - Data retention
    - Archiving

    Printing

    Your SAP printing strategy can often be a challenging exercise, particularly with a global deployment across multiple offices that may have mixed print devices, drivers, connections etc. Below are some key areas to focus on when designing your print strategy and how best to address each.

    > What are the printing requirements?
    - Consider the type of printed output your offices will most likely produce (e.g. invoices, reports etc.), and determine the printing needs of each office > Where are the printers located?
    - Work with your infrastructure and networking team to produce a visual map of your print landscape, along with an inventory of IP addresses, drivers, versions, models, connectivity type etc.
    > Is there a printing strategy in place from the business?
    - Work closely with each office and your business units to determine their printing needs; and then try to converge those needs into a homogeneous solution that works for everyone and can be more easily deployed than targeted/custom solutions
    > Are print servers currently used?
    - This will help in determining how you leverage SAP PAL
    Will there be a need for special forms printing?
    - Special printing like barcodes, for example, require solutioning on SAP custom forms; consider these and account for them as part of your custom development efforts and whether your printers will support their output
    > What are the batch printing requirements and how will they be addressed?
    - Some other points to consider with batch printing is how the batch job will be delivered to either internal printers or external printing services

    Supplemental to this effort, SAP provides tools and resources such as the Output Management to establish your printing infrastructure and design. Below are key benefits with PAL:

    > Configure printers centrally
    > Distribute printer configuration to other systems
    > Keep printing jobs in each system as before
    > Group printers and target systems for customized organization
    > Get printer status such as paper jam, empty tray, off-line, etc.

    Interfaces

    In most instances, the starting point of your interface landscape is from your Component Business Model (CBM); put forth by IBM a few years ago, it helps create a "heat map" of your functional/technical/geographic units and processes. From these CBM maps you can derive your:

    > Enterprise Service Oriented Architecture design
    > SAP integration/interface design
    > Legacy-to-SAP interface strategy and "legacy system retirement" planning
    > External systems integration (e.g. EDI, banking, warehouses etc.)

    Implementing this design is where SAP Netweaver Process Integration (PI) steps in; a component of "the Netweaver product group used to facilitate the exchange of information among a company's internal software and systems and those of external parties". PI offers a variety of standard adapters to interface with file-based formats, XML etc., however in some instances requires the addition of 3rd party tools/adapters to support SFTP, EDI and other more-complex formats. Companies such as Seeburger and Advantco are typically your most common vendors on the market, and also provide great "central monitoring" tools to keep your interfaces running in shape and closely controlled.

    Look for a more detailed article on Netweaver PI in my future posts; including best practices, communication techniques etc.

    Beyond some of these key areas to consider when designing and deploying your SAP infrastructure, topics such as backup and recovery, high availability, disaster recovery, networking and security (e.g. ports, VPN etc.), end-user access (e.g. SAP GUI, Portal, AccAD etc.) are just some of the many topics to consider to get your SAP infrastructure done right... Best of luck, and remember that you can only be as successful as your design!
    As a new participant in the "SAP Universe", one of the first things you will likely encounter during the preparation and readiness phase of a project (referenced in my prior post) is a review exercise for several key documents and templates. Bearing in mind that these documents serve as a foundation to conduct/govern your work, collect and document your requirements, and manage the overall project, a significant effort needs to engage in order to maximize the potential of these documents and the value they add to the project.

    So let's get started with a review of some key documents and templates you will come across and how best to approach and successfully contribute to the content and structure of each.

    Inventory of Deliverables, Responsibilities and Acceptance Criteria

    This document contains the project's inventory of core deliverables, who is responsible for each and what the general acceptance criteria is to sign-off the completeness of each deliverable. This document will typically contain items such as:

    > Project Management: review of roles/responsibilities of project members, impact of other projects, scope review, developing the detailed project plan, establishing workshops, establish risk assessment processes and sign off the detailed plan
    > Change Management: develop the change management roadmap, engage key stakeholders to review change impacts, develop a communication plan and conduct awareness sessions with key resources and stakeholders
    > Standards and Rules: establish documentation and approval procedures, define issue/quality resolution and change request procedures and define communication and meeting structure
    > Technical Planning: define the infrastructure requirements, purchase and provision hardware/software and define the architecture outline

    Architecture Approach and Design Templates

    This is generally a very high level document that outlines the key technical deliverables (e.g. integration with other systems, replicating legacy systems and SAP for their retirement, key technical architecture decisions etc.). These technical deliverables are further backed by a high level impact review on processes, custom developments, data, resources, testing and project timelines. The purpose of each impact review is to set expectations with the project, and set a baseline for the potential work involved in the more significant project deliverables.

    Change Request Template and Procedures

    Very simply this the project's change request template document that will be used to document every change request's overview, requirements, effort and timeline. Underlying procedures also need to be clearly defined so as to avoid any failure in tracking approved/declined change requests during the lifecycle of the project. Such procedures dictate the steps required to approve/decline a change request, update and resubmit, where to store these documents, how to log each one etc.

    Change Vision and Management Roadmap

    The change vision and management roadmap provides a vision for why the company is engaging in the implementation, clear focus on the effort and a baseline to work from. The vision facilities the clarity of what is being achieved from a business and technology standpoint (e.g. simplifying processes, achieving operational efficiency etc.). Supplementing the change vision is the management roadmap which outlines the key change management tasks to achieve:

    > Program leadership and governance
    > Organizational design
    > Stakeholder engagement and communications
    > Delivering the necessary skills and knowledge
    > Culture transformation and new ways of working
    > Program strategy and management

    Client Landscape Strategy

    One of the most important technical documents in the project, and often overlooked, the client landscape strategy documents the SAP environments making up the landscape for the project through its major phases. The SAP environments typically comprise of the following systems:

    > Sandbox: used for prototyping, demos and experimental work prior to development
    > Development: used for all development and configuration activities, including unit testing and master data creation
    > Quality Assurance: used for integration and user acceptance testing, including end user training
    > Production: used for the production environment
    > Production Support Development (optional): used for configuration and development of production support fixes (snapshot of QA at time of go-live)
    > Production Support Quality (optional): used for testing of configuration/development of production support fixes

    This document further outlines the release strategy between each system, timing of each release, governance of how data and packages are sent across each system and how each client should be used... to name just a few. Expect this to be a large document, very detailed, and sufficient for everyone in your technical team to understand and reference regularly when managing the system landscape.

    Data Migration Scope and Requirements Document

    Data Migration Scope/Requirements are important topics that must be covered as early as possible to avoid uncomfortable surprises from occurring in late phases of the project. The data migration scope identifies the data objects that need to be transferred from the old (e.g. legacy) system to the new system during an SAP project. When data migration is part of the scope of the SAP project, discussions on the data migration scope should be initiated as early as possible and the outcome of these discussions should be clearly mentioned in this document.

    Document Approval Procedures

    Similar to the change request procedures document, this document outlines the procedures for approving any business, process or technical document produced from the project. It sets governance for how documents are finalized and signed-off, which is crucial between every major phase on the project.

    Interdependancies Review

    Typically a thorough review of all potential projects running in parallel, systems and external/impacts that the SAP implementation might depend on or be impacted by. Obviously necessary, but often overlooked.

    Issue and Risk Log

    The issue and risk log is a basic Excel template shared amongst project members to log issues with the project, potential risks, and how to avoid/resolve them. Typically the PMO and integration managers are key people in driving the resolution and planning for items collected in these log files. Making sure the template captures thorough details is key; owners, deadlines, comments, dependencies etc.

    Knowledge Transfer Strategy

    This document is used to define the processes, scope and approach for conducting effective knowledge transfer activities between resources rolling on/off the project, and/or providing the necessary knowledge/training to the end users prior/after go-live of your system.

    Meeting Minutes Template

    Very basic, but an important document to constantly use in meetings and workshops. Having a well thought-out meeting minutes template, that is also very simple to use and fairly automated, will help keep project members actively engaged in documenting the outcome of all meetings and workshops while assigning the relevant actions accordingly.

    Naming Conventions

    Formalizing naming conventions in any system is important; in SAP, it is even more critical as these naming conventions trickle down from documents, to system configurations, developments, testing, and training documents. Things such as custom development (WRICEF) ID number format, configuration code format/structure, data naming conventions etc., are all important to capture and document in this deliverable.

    Project Plan

    One of the most important documents in a project, and often poorly managed; simply because managing a project plan in a tool like Microsoft Project is a full-time job in itself requiring a significant amount of mathematical wizardy, organization and structure. From personal experience, segmenting the core project plan into several pieces can be very helpful; for example, broken out by each workstream. This allows you to easily manage it, and control the updates accordingly.

    During the readiness phase, reviewing and finalizing this document is critical. Every task, date, predecessor and timeline should be reviewed with all the key project members, stakeholders, PMO and team leads.

    Quality Review Procedures

    This document defines the processes and expected output of a quality review effort in the project. Quality planning is defined by the functionality, performance needs, measurement and verification requirements, and also governed by change/config management, standards to adhere to (e.g. technology/accounting standards), and methods/tools used to drive these efforts.

    Other Preparation/Readiness Information

    Below is a list of other useful resources to consider during the preparation/readiness phase:

    > Ramp-up Knowledge Transfer (RKT)
    - RKT delivers early product and task-related knowledge to experienced SAP and partner consultants in Ramp-Up projects and to all other roles such as sales and customer's administrators involved in the SAP Solution Ramp-Up.
    > Updated SAP ASAP Roadmap 7.0
    - The new ASAP Methodology For Implementation released to access further information on the updated roadmap
    > Accessing the ASAP Roadmap
    - ASAP 7.0 delivered in SAP Solution Manager to read about how to access the roadmap via Solution Manager

    Look for details on SAP technical architecture design and planning in my next few posts...
    With over 100 certifications to choose from, across two certification levels and three focus areas, navigating the SAP Certification landscape can be a daunting challenge in itself. Planning and executing your educational roadmap with SAP can also be as daunting, and likely overwhelming, if you are unable to dedicate the time, plan accordingly and prepare for the exams.

    So, still interested to take that adventurous and brave leap into the "SAP World", and earn your credentials in SAP? Yes? Then read on...

    In summary, few credentials in the technology space carry the value of SAP certification. Those who hold it have managed to hone their skills through rigorous study or direct experience. They have demonstrated their abilities by passing demanding, process-oriented exams. SAP certification, without question, can give you the distinct competitive advantage you need to accelerate your career, sharpen your SAP skills and enrich your overall functional/technical background.

    Below is a summary of SAPs three certification focus areas:

    > Application Certification
    This certification focus area is available for specific SAP solutions such as PLM, MDM, Netweaver, BW, Data Integrator, Accounting, Planning and Manufacturing etc. Ideally a good certification path for the more functionally-balanced candidates interested in sharpening their business-process skills within the SAP landscape.

    > Technology Certification
    This certification focus area is available for technologies such as PI, MDM, Security, Portal etc. Ideally a good certification path for the more technically-balanced candidates interested in sharpening their technical skills within the SAP landscape.

    > Development Certification
    This certification is available for individuals who are developing applications on SAP. It covers development languages/tools such as ABAP and Java, and caters to the development-type candidate who has an interest in refining their software development skills.

    So how does one get started? Where and how do you get training? What is the certification exam like? Below is a breakdown of the training options available and a first-hand experience in the certification exam process...

    Offline Training

    Offline training involves classroom training primarily; these are 2 to 5-day instructor-led courses supplemented by PowerPoint presentations, lab-type exercises, hands-on SAP exercises and reading/referencing training manuals that are anywhere from 300 to 1,000 pages long (hehe, ya, i know).

    These types of offline trainings are best suited for most courses in the application, technology and development focus areas. Every certification has a clearly defined training path, which often includes offline training prerequisites to get to the certification itself. There are some application certifications, for example, that offer training entirely online with a one-day certification exam held at a training facility.

    Below are some useful tips and tricks to leverage when taking SAP classroom (offline) trainings:

    > ASK For exercises and labs that have complex steps/scenarios, always ask the instructor for help and to conduct walk-throughs. They have done this enough times to know the work-arounds and tricks for a problem.
    > BREAKS The in-between breaks during the morning and after lunch are crucial; you need some down-time and coffee to recharge your body and re-focus. Remember, there is a lot of information to absorb in very short amount of time; don't underestimate it.
    > CONTEXT Try to understand what your are learning fits in the context of your project and/or workplace. A good exercise is to take a specific example of a problem you are facing on your project, workplace or prior experience, and map it into what you are learning so you can figure out how to resolve it in the future.
    > DIAGRAMS Review the diagrams for each section and try to understand what they mean; the instructor usually references them, and whatever explanation and walk-throughs they provide should be noted down to help understand what the diagram means.
    > ENGAGE Most importantly, engage with your instructor and fellow-students. There is a reason for taking classroom trainings; it's not just about learning in front of a teacher instead of a computer, it's about interacting and really getting the most out of the experience.
    > FOCUS During the presentation of the course, most instructors tend to walk through the chapters with the SAP-provided PowerPoint presentations supplemented with their feedback. It is important that you focus on the specific sections within a chapter that the instructor covers, as very often they know best what the certification covers.
    > HIGHLIGHTS Take note of anything "flagged" as important in the training material (e.g. Hints, Tips, Notes etc.); they often provide that additional piece of information to help you get through the section and fill that "understanding gap" for a concept.
    > INTERACT Ask questions to understand what is being presented. Often-times the last few hours of a class lead into absorbing so much information with nobody asking questions; this is a fatal risk that should be avoided by being more interactive and engaging with the instructor to review your understanding of the problem.
    > NOTES Take hand-written notes in the training material, supplemented by a copy of the notes electronically in Notepad (if the training computer allows).
    > READ Read ahead every step and VERY carefully in the exercises and labs; chances are if you missed a step in the exercises, the final result will fail completely. It is a common mistake to jump through exercises quickly and end up with a poor result.
    > REPEAT If you think you understand it, you probably do not. Repeat the topic to the class to improve your understanding and take notes.
    > REVIEW It sounds boring and exhausting, not to mention finding the time, but simply taking a day out of your weekend to review your training a week or a month after the course can be extremely helpful in retaining your memory.
    > SCHOOL Use your best traits... Remember your school days? Ok, probably not, but if you do, try to leverage some of the very same studying techniques you did at school (e.g. repetition, studying the day before, staying later to review the day's work etc.)
    > Finally, and most importantly, have fun!

    Online Training

    The online training experience provided by SAP Education is surprisingly well structured and presented using animated presentations, point/click activities and hands-on training via SAP training instances through remote desktop-like sessions. This training delivery option provides only a handful of courses and certification options; best suited for obtaining your associate certification fairly easily and within your studying schedules to accommodate work hours etc.

    The content of the online trainings are mostly based on the offline courses; typically the same material is used, and you can even download a PDF version of the large training handbooks for that specific course. The trainings walk through narrated slides and animations, backed by material from the training handbooks.

    Below are some tips on how to best succeed with these types of courses:

    > BREAKS Always take breaks; helps to refresh your body and mind so you can prepare for the next section. When you find yourself reading through material that stops making much sense (e.g. reading for the sake of reading), then is about a good time to take a break and re-motivate yourself.
    > COMPLETENESS Studying through everything and conducting all the tests and exercises is essential. Complete the training from start to finnish; skipping sections/units (unless absolutely necessary) is a good practice to avoid missing key concepts.
    > DEDICATION Dedication is one of the most important parts of online trainings. Keeping to a strict schedule and maintaining a steady momentum is usually hard to maintain, particularly when surrounded by work and personal distractions. Locking yourself in a room, or going to study elsewhere is often the best solution; you simply have to unplug from everything else and reserve a set amount of time to focus.
    > NOTES Very much like offline training, taking notes is key. Being that the training is delivered via your computer, maintaining your notes in Notepad or Word can be much more effective than handwritten notes (e.g. searching text, formatting content etc.)
    > REVIEW Revisit the review sections of each unit often. They provide key information for the unit that are excellent in referencing when you take the actual exam.
    > LABS Always do the lab/interactive exercises, they are extremely helpful as a refresher and a way to secure concepts in your mind.
    > TIME Taking the time to complete online trainings can often be hard. Usually weekends are your only option, and this can lead to a 2-3 month period for courses that are built across 5 to 10 full days of training material. So plan your time accordingly and execute.

    In summary, online trainings are best suited for the more basic training and certification packages, and really best suited for those who have time on weekends to study. Dedication, repetition and avoidance of procrastination are some of the most important things to keep in mind while engaging with these formats of training delivery.

    Taking the Certification Exam

    The SAP certification exam is designed to be challenging; take my word for it! Most are offered as a 3-hour exam (breaks are optional), with 80 questions and typically a 55% pass-rate... Think about it, that's about 2 minutes per question (excluding breaks), and each question is a complex multiple choice (e.g. a question can have one or more answers out of many, and most questions are scenario-driven). Given that amount of time, and necessity of thinking through questions methodically and carefully, you will need to be very prepared.

    Worst case, you can take the exam up to three times per year, with an elapsed interval between each retake (rules might have changed already, so don't quote me on that). In any case, below are some tips on how to prepare for the exam and use techniques during the exam to succeed.

    > BREAKS Given the short amount of time, it is very hard to take a break. Inevitably, your body will need it, so try to plan for one break every hour; usually 2-3 minutes for a quick stretch and bathroom break works best.
    > COUNT Keeping count of your answers is a handy method to gauge your possible pass-rate. If you feel 100% confident about at least 60% of the questions, then you are in a fairly good shape to get to the 60+% you need when doing the final review at the very end.
    > FLAG Use the flagging functionality for questions you are not sure of. It is VERY helpful when revisiting questions at the end that your uncertain of.
    > NOTES Use your note sheet to create diagrams of the scenarios presented in the questions. Also use it to keep count of confident/non-confident questions you answered.
    > READ Read the questions very carefully; they are often scenario-based and you have to understand it very well before answering or considering the multiple choice answers.
    > RELATIONSHIPS Believe it or not some questions have relationships to others, so it is good to keep a tab in your mind or note sheet of some of the more complex questions as others might be related and answers could be "deduced" if you are clever enough ;-)
    > SCENARIOS Since most questions are scenario oriented, requiring some effort of thinking, try to play them out in your mind as if you were doing them in real life. This can often help confirm your answers.
    > TIMING Keep time; watch the clock on the screen, and time yourself with your own watch. Remember to keep it short, quick and efficient per question; 1 to 1.5 minutes per question is usually a good strategy, this way you gather enough buffer time for breaks and doing a final review at the very end.
    > TITLES The titles of every question often provide a good context for what to expect, so make sure you read the title/topic before reading the question.

    Last, but not least... Prepare, Prepare, Prepare. Before taking the test review your notes and training material. It is often very helpful to review the summary sections of each unit; you will find most of the complex concepts documented there that are often used in the exams.

    Keep studying, and best of luck!
    Patrick Rayes

    An SAP Experience

    Posted by Patrick Rayes May 12, 2010
    Systeme, Anwendungen und Produkte... German for Systems, Applications and Products, or SAP. Founded in 1972 by five former IBM engineers, and now headquartered in Waldorf, Germany, SAP is the largest software enterprise in Europe and the fourth largest software enterprise in the world. Almost $15 billion in revenue, nearly 50,000 employees in over 50 countries, 90,000 plus instances of SAP running worldwide, 2,400 certified partners and a network of nearly 1.5 million developers in over 200 countries... SAP is, per their very well-known statement, run by the "best run businesses". Got your attention?

    Why write about SAP? Long story short, having recently been involved in a global implementation of SAP with challenging and diverse implementation phases, a "personal experience" review seems fitting to share with those out there entertaining the thought of embarking on their own SAP career or project. However, before commencing with a "tsunami" of articles on my experience with SAP, below are some of the basics to set a foundation of what the "SAP Experience" is all about...

    Awareness and Preparation

    Implementing SAP at any level, small or large, can have profound organizational impacts that require a highly effective awareness and preparation strategy from all levels of an organization.

    Why, you may ask? First and foremost, because SAP is a highly structured product that requires a unique way of thinking and conducting business so as to fit within its robust processes. Secondly, SAP can potentially uproot and revamp a single department's processes and resources, despite that department's highly coveted, proven and "set in stone" business processes. Third, and generally this applies with any technology, the learning curve and usability element can be immense. Not to mention everything else that SAP brings with it; business change, organizational alignment, IT system readiness etc.

    Combining these "ingredients" that SAP brings into an organization necessitates planning for awareness. Awareness and alignment across all levels, and preparation towards reaching that goal; communications, workshops, executive buy-in, sponsorship  etc. You essentially have to elevate the organization into a level of awareness and preparedness so as to pave the road towards a successful implementation.

    "Method to the Madness"

    Where does an SAP implementation start and how? One of the most commonly used and known frames of reference, supported and backed by SAP, is the Accelerated SAP Roadmap (or Methodology). ASAP is a comprehensive solution and roadmap for the implementation of SAP, comprising of a proven methodology, tools and a range of services for the rapid implementation and ongoing optimization of SAP installations.

    The ASAP Roadmap and accompanying project plan provide a standard implementation "how-to guide" that fills in the gaps of diverse methodologies and varying individual implementation skills and experiences. It is broken down into five main phases (listed below):

    Phase 1: Project Preparation

    > Decision-makers define project objectives and decision-making processes
    > Project charter issued and implementation strategy outlined
    > Project team and working environments established
    > Establish kick-off and workshop meetings to engage the project and assign responsibilities

    Phase 2: Business Blueprint

    > Document and define the scope of the implementation in a Business Blueprint
    > Application consultants, process teams and technical counterparts, achieve a common understanding of how the enterprise intends to run its business
    > Engage the project team in training in SAP fundamentals and processes

    Phase 3: Realization

    > Configure the SAP system to fulfill the business process requirements
    > Baseline configuration: configure about 80% of daily business transactions, master data, organizational structure
    > Final configuration: remaining deliverables within each process, including customizations to the system

    Phase 4: Final Preparation

    > Integration testing, User Acceptance Testing and Quality Assurance
    > User training and cut-over activities
    > Resolve all crucial open issues

    Phase 5: Go Live and Support

    > Supporting end users
    > Establish procedures and measurements to review the benefits of the implementation
    > Address any remaining open critical issues
    > Implement SAP services: Online Service System (OSS), Remote Consulting, EarlyWatch Services

    Most SAP projects will encounter these common phases, and some will even engage specific and highly focused activities to blend into the organizations way of doing business and thinking (e.g. inter-departmental and divisional workshops to align key stakeholders and business process owners).  Combined with other tools such as the Enterprise Services Repository&Registry, the ASAP Roadmap can prove to be a very effective baseline for kicking off a SAP implementation.

    However, as many SAP projects engage a solution vendor (e.g. CapGemini, IBM etc.), you will likely come across a vendor-specific methodology such as IBM’s Ascendant Methodology. These methodologies are blended to suit the tried and tested best-practices established between SAP and the solution vendor.

    Everything Else

    Just when you think you had everything sorted out with the SAP methodology and roadmap, there are numerous areas to consider that are critical to every phase of the project. Just a few of them are outlined below, each with a brief description:

    Architecture
    Everything from the business, functional, technical, solution and data architecture need to be considered and clearly defined. This acts as a visual roadmap for your functional teams, business stakeholders and overall project team to steer along; it sets governance, best practices and confirmed design decisions on paper.

    Champion/Expert Users
    These are a group of users that have gained incremental experience in using SAP during its initial rollout and have a significant influence in an organizations business processes. They are the frontline to addressing issues with the user community, and the extended support network and business process facilitators for SAP.

    Change Management
    As mentioned earlier, change management is critical to align and prepare an organization for the changes that SAP brings into an organization. This involves constant communication on each critical phase of the project, awareness to the user community and business stakeholders, workshops to help bring understanding and knowledge of what to expect and how to contribute etc.

    Center of Excellence (CoE)
    The CoE is one of the most important components to establish during the final phase of a SAP rollout. This team comprises of SAP-skilled individuals, with strong relations to business process stakeholders, to help support and lead the growth of SAP in the organization. Everything from support issues to system enhancements and data management; the CoE is charged with owning and driving the growth and success of SAP within the organization, while bringing the necessary awareness and knowledge to the user community for operational efficiency and stability.

    Communications
    Keeping your organization well-informed on the progress of an SAP implementation, and what it means to them in understandable concepts, is key to a successful rollout. Inter-project communication tools and processes is also an important part of a global rollout; particularly with teams spread across multiple timezones.

    Governance
    Governance implies having a set of rules, processes, guidelines etc. that dictate how certain key phases and deliverables of a project need get done. Governance can be enforced by a steering committee, key resources on the project team, and even the PMO. Without governance, you can very easily expect project deliverables to get misaligned and go off course.

    Hypercare and Sustain Phases
    Typically after every major project rollout, a sustain/support phase is engaged to make sure the system is stable and operational according to the design. This period can typically last several weeks, as the organization settles into the new system and all the critical issues that prevent the business from operating efficiently are resolved.

    Integration Management
    Integration management can usually be a new concept for most project teams, and one overlooked and not effectively filled. Integration managers are charged with the responsibility of making sure all the various work streams and functional teams are aligned on their expectations from one another. Case in point, changes done to the sales process within SAP might have effects on the financial accounting processes, hence integration management's involvement to align these changes.

    Master Data
    Master Data, Master Data, Master Data. As goes the saying for real estate where location is key to any successful real estate venture, master data for SAP is key to a successful implementation. An organizations master data is all the customers, vendors, products etc. configured and setup within SAP as a "single source of truth", providing data to dependent systems and/or synchronizing/harmonizing with external systems.

    Offshore Team Management
    Any project without an offshore team somewhere in the world is likely no project at all, as today's typical global IT project has a dedicated team offshore developing and testing the system during the realization phase. Offshore management skills are critical to keep under control and well-monitored. Everything from culture-clashes, to making sure your offshore team has everything they need to be successful is crucial.

    Portal vs SAP GUI
    When it comes time to selecting your method of providing access to SAP for your users, there are several choices. Two of which are the Enterprise Portal (a Web-based interface that replicates the SAP transaction screens online), and the SAP GUI (client-based software). Selecting between each can be a challenging architecture decision, and can affect the success of how your end-users use the system effectively.

    Project Management and PMO
    Here is where the SAP methodology and project plan come into play; the success of delivering a SAP project on time and on budget depend greatly on the success of the PMOs enforcement of the project plan, charter and overall methodology.

    Project Sponsors, Stakeholders and SMEs
    Every SAP project of significant size requires a blend of sponsors, stakeholders and Subject Matter Experts (SMEs) to help guide the project towards a successful design and implementation. The sponsors to make and enforce key decisions as well as aligning and preparing the organization for SAP. The business stakeholders to support the project team in making decisions on the design. The SMEs to articulate the specific technical/functional requirements for key areas of the implementation.

    Release Management
    Release management can be a significant challenge during the initial and subsequent phased rollouts of SAP. Control over the changes that go into the system need to enforced, not just for auditing purposes but also to help keep the project team aligned with what the system baseline is between each phased implementation.

    SAP Netweaver and SOA
    Commonly misunderstood, and highly overlooked. SAP Netweaver is SAP's integrated technology platform and is the technical foundation, providing components, tools and applications, for all SAP applications since the SAP Business Suite. SAP NetWeaver is marketed as a service-oriented application and integration platform; it enables you to consolidate heterogeneous systems, applications, and data to simplify your technical landscape. The key components of SAP is what makes up the solution overall, and dictates the enterprise architecture, including most technical and solution architecture components.

    System Sizing and Infrastructure
    Typically done during the early stages of the project, the sizing exercise is meant to help your IT team document the hardware, network and software inventory required to deliver the SAP landscape. This can often lead towards a little technical “black magic” to identify the acceptable size of equipment and setup required to run the SAP system for the size and number of users.

    Status Reporting and KPIs
    Maintaining a healthy and steady pace on a SAP project requires constant monitoring and measuring, often controlled by the project PMO. Key Performance Indicators to give us a visual on the health of the project, and status reports to expose the progress of each team and their deliverables.

    Team Structure
    Often an interesting topic for those wanting a “slice of the pie” in the project, and usually the first topic on the table. Although the team structure, and whom reports to whom, can be important to finalize, it should be well controlled and monitored so as to not create an imbalance in roles and responsibilities that would lead towards failure and/or corrosion of trust and effective teamwork.

    WRICEFs
    Workflows, reports, interfaces, conversions, enhancements and forms; the laundry list of custom developments that would be required to make SAP work for the organization per the design/blueprint put in place. Often argued as an aging practice of classifying the custom development roadmap on a project, it has been proven to help align the planning and organization of all custom requirements in SAP.

    So there it is, in about 2,000 words... More to come on my next series of articles; stay tuned!