patrick.rayes

    August 2010 Previous month Next month
    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.