If you are going to be at SAPPHIRE, please drop by Patrimonio’s session for a viewing of the video, an interactive discussion and more information on SAP BPO best practices:

Real-Life Integration and Process Management

Wednesday, May 19

3:00 – 3:20 PM presentation

3:30-3:50 PM discussion

Theater 3 Lines of Business

What is SAP ESR

• SAP ESR is the evolution of Integration Repository (IR) in SAP XI. IR was already representing the end points as message interfaces. Message Interfaces were already exposed as WSDL. SAP has added the Modelling capability for Process Component Models (which is an extension on top of the earlier Integration Scenarios), and streamlined the usage of end points (now called Service Interfaces). It has also streamlined the usage of data types which are now called global data types.
• The service organization concept is similar to that of IR. All Service Interfaces are within a SCV and a namespace.
• SAP ESR provides the advantage of providing a consistent naming convention of Service Interface.
• Enterprise Service Builder (ES Builder) offers a modeling environment to create various models in the Enterprise. It was earlier called the Integration Builder in the SAP XI environment.

Salient features of SAP ESR:

• ES Builder allows to create Process Component Model (ProComp Model)
• In SAP NW 7.0 (2004s) and SAP NW ‘04, service interfaces have one operation per service. In SAP NW PI 7.1 the Enterprise Services Repository offers multiple operations per service.
• Global Data Types: Approved SAP-wide using the Governance process. Reusable semantic building blocks for service interfaces and message types.

Why to use SAP ESR:

• SAP ESR is the central repository for modeling the service interface. We model the service operations, and their request/response structures. This allows us to have a CENTRAL enterprise wide repository for managing these definitions.
• SAP ESR provides the capability for organizing the service definitions based on software components, their versions and namespaces. It also allows us to maintain service versions (since services invariably would get revised over time).
• Enable SOA design governance across the organization. We can model the Process Component architecture models in ES Repository. From the ProComp models, we can drill down to standards based service interface design (Service Metadata). The service interfaces are based on GDTs that provide resusable uniform representation of business structures.

SAP ESR is positioned to be the central enterprise wide repository for managing all service definitions for SAP and nonSAP services.

Our recommendation for SAP customers is to use SAP ESR for modeling and managing all SOA service definitions for SAP and non-SAP services across the enterprise.

Design Principles for service design and identification:

1. Granularity: The service should have a broad level functionality to be sufficiently useful to a large range of consumers. The service should not be too fine-grained i.e. not have a narrow functionality to be of use to a limited set of consumers.
2. True reuse at the Enterprise level: The service should have functionality to be of use across the enterprise by providing generic functionality in its functional domain.
3. Durable (standing the test of time/change in the landscape): A good service would stand the test of time and the test of constant change in the enterprise landscape.

Best Practices for Technical Characteristics

1. Idempotent: The Service should provide the same result when called more than once. In web service operations, due to technical failures, the caller may not get a valid reponse to its service invocation. The caller would invoke the business service again, which would lead to a repeated business transaction (an obvious blunder). Hence, for transactions, we have to ensure that the business transaction happens only once. A design approach is to use a unique GUID in the web service call, which would be used in the service response to correlate the request-response. In case of a repeated service invocation, the duplicate call would get detected due to the repetition of the unique GUID parameter.
2. Security Considerations: Considering the broad appeal of the service across the enterprise, many consumers are expected to invoke the service. Hence, it is important to control the security aspects of calling this business service such as roles, authentication and authorization. Even if the service is not a transaction (not committing any business data) and if it is a read-only service, the security has to be controlled to restrict the data subset being requested by the caller.
3. Error Control: Due to the distributed nature of services and participation in distributed business processes, the service should fail elegantly and provide a human-readable trace to provide an easy method to troubleshoot error causes. Additionally, the service should reverse-compensate any business data transactions on encountering errors and preserve data integrity.

The above are the essential aspects for designing good services that endure the test of time. These learnings are based on our direct experience in identifying enterprise services and establish SOA design and governance principles across customer projects.

SAP runs most of the core business processes across its customers. The SAP Business Suite provides comprehensive transactional support for core business processes such as financials, sales, procurement, manufacturing, operations, HR etc. SAP has built a rock solid business process platform for managing these core processes on the SAP application server to manage processes within the SAP ERP product.

With mergers, acquisitions and extended supply chain, the business processes are spanning multiple systems and business partners. SAP has recognized this industry need; SAP has a clear roadmap towards business process execution and management for extended processes spanning multiple systems, applications, users and partners.

SAP BPM suite is the business process platform for managing these extended processes. However, the SAP BPM product set is a relatively new entrant in the well entrenched BPM market. Hence, customers would tend to evaluate SAP BPM with the mainstream BPM vendors before taking a decision on the BPM adoption.

A few important BPM product evaluation criteria are:
1. Support for long running processes, process versioning, compensating transactions
2. BPM infrastructure related to performance, load balancing and scalability
3. Integration of business rules
4. Security, role based access
5. Reporting capabilities
6. Business activity monitoring
7. Simulation capability
8. Design and Development environment, productivity
9. Operational support, monitoring and management
10. Pricing, vendor stability, installed base, customer references, consultants availability

SAP BPM may not hit the top place today in comparison to the best-of-breed BPM products. However, SAP customers need to look at the holistic view of adopting and standardizing on the SAP platform for all their business and technology needs.

Advantages to standardizing on the SAP BPM platform:
1. Native integration with SAP Business Suite
2. Rapid prototyping capability for integration to SAP suite
3. Reuse of your team’s skills in SAP development using WebDynpro and ABAP
4. Integration with SAP security and consistent role management
5. Familiar SAP Portal look-and-feel to users for SAP BPM interactions
6. Unified monitoring through SAP Solution Manager
7. Pricing in line with your contract for the SAP product bundle

Our recommendation to customers having a SAP-centric strategy is to adopt SAP BPM for business process management. SAP BPM is central to SAP’s strategy on business process management, and the product is getting better with every release. Native integration to SAP products (SAP ECC, SAP SCM, SAP CRM etc.), usage of skills of the SAP development team and faster development would outweigh the adoption of a new BPM product in the long run.

MES stands for Manufacturing Execution System which is used to manage the operations; for example, production order, process data, work instruction storage etc. It is related to the manufacturing and operations. The main purpose of any MES system is to gain visibility, flexibility in operations and manage the supply chain effectively along with consistent documentation. In the market, there are numerous MES systems specific to industry type, product nature and manufacturing complexity.

In general, MES is vendor specific and as per explicit need of the customer. MES systems are independent of ERP systems and are “add-on” software. Usually, it is difficult to find all our requirements in any ERP suite that can manage the complex manufacturing flow of products; in such situations, specialized software products such as MES are suited, where ERP functionalities are not sufficient to run the operations. Indeed, MES assists in achieving the multifaceted requirements of the organization.

At the highest level, MES needs integration between the ERP and shop floor automation. SAP maintains the record of materials, BOM, routings and orders; the MES maintains the records/transactions such as WIP (work in progress). For implementing the MES, the consultant has to perform detailed analysis of MES requirements such that they can be mapped with the manufacturing environment. The consultant has to perform the analysis of the integration with SAP PP since there is overlap of functionality offered by SAP and MES software.

MES plays a major role when there are many shared resources or work centers, complex routings (master recipes) and substantial effort to manage the production of material into finished product. MES increases operation excellence and manages asset and its utilization, which in turn reduces overall operational cost of the business.

MES provides capabilities such as plant data collection, production process quality management, order tracking; additionally, the MES system provides detailed scheduling of operations, production process management, performance monitoring, resource allocation, manpower allocation and management control of engineering documents. Resource allocation can be manual or automated in MES. There is real time exchange of messages between the SAP ERP and MES system regarding various facets of the manufacturing operations. Let’s say in case of production management, one can easily download production schedule from SAP to MES system, upload production confirmation/consumption to SAP.  In case of asset management in MES, we can download equipment list from SAP and upload equipment runtime data to MES.

ISA (Instrumentation, Systems, and Automation Society) S95 standard describes the connectivity between ERP and the MES system; this includes MES functionality and database schema, message formats between application systems etc.

Integration – There are two major integration options for MES integration with SAP
1. SAP xMII (Manufacturing Integration and Intelligence) – SAP xMII facilitates real-time transactional integration between plant shop floor and enterprise (SAP ERP) systems out-of-the box. By using the schemas available in the xMII repository, we can perform faster integration between xMII and the MES systems conforming to the IS95 industry standard interfaces.
2. SAP PI : This is the integration middleware platform within the SAP NetWeaver suite. We can use SAP PI to exchange information between the MES and SAP ERP products.

SAP CAF provides discrete steps or activities which can be assigned to a role. The activities in the SAP CAF process can exchange data through process context parameters which is similar to a “global memory” where the common process data can be placed and can be accessed from any step in the SAP CAF process.

Though SAP CAF provides a rapid development facility of providing a code-free activity for common integrations such as web service, RFC …, in real world business processes, we have to use custom developed WebDynpros to implement each business process step.

Our design recommendation for SAP CAF processes is as follows:

1. Do not use the CAF process context for exchanging business data. Keep the process context light. Instead, use a unique process identifier across the process steps to identify the currently running process.
2. Design each process step as a standalone WebDynpro application. While establishing the functionality of this standalone WebDynpro application, think of it as a reusable component which can be reused later in any future business process step. The only input to this WebDynpro is the unique process instance ID. The standalone WebDynpro application would retrieve the business data from the persistent storage based on this process ID, and present the User Interface to the end user. The user would provide business data to this WebDynpro application; the WebDynpro would conduct its business processing; it would persist the business data into the persistent storage and mark this step as complete.

SAP BPM is similar to SAP CAF in the business modelling and process steps:

1. There are business activities in the business process model
2. SAP BPM provides process context for storing process specific business data.

In our experience, if we conduct the design based on our recommendations for SAP CAF process implementation, the migration effort to SAP BPM is significantly reduced. The WebDynpro applications need minor changes to conform to the SAP BPM framework vs the SAP CAF framework for calling WebDynpro methods.

In conclusion, our recommended design approach for standalone WebDynpro design towards reusability, and exchanging minimum data in the process context has stood the test of rapid migration from SAP CAF to SAP BPM with minimum effort or rework.

• SAP ABAP workflow is meant to streamline a business process that is completely contained within the SAP server. Typical usages are procurement approvals, leave or travel approvals etc where all the business data and business objects are within the SAP instance.

• SAP PI BPM is used for cross-system integration and managing a higher level business process between disparate systems. A typical scenario is a Sales Order acceptance process where several systems would need to be consulted before accepting the order such as a inventory check, global ATP check etc.

• SAP CE provides workflow capability at the User Interaction level where the user can see a sequence of screens to complete a business process. SAP CAF was the workflow product to provide the BPM capability for implementing a UI centric business process.

• SAP BPM is now replacing the SAP CAF product set to provide a standards based BPM capability. SAP BPM provides modeling and implementation for a UI centric business process – we can develop the business process based on the BPMN notation supported by most mainstream BPM modeling tools.

• SAP MDM workflow is a lightweight workflow capability within the SAP MDM product to allow the various processing steps for master data management such as cleansing, deduplication, referential integrity and broadcast to other consumers. It is a workflow engine for exclusive use within the SAP MDM product set for finer grained processing.

• SAP BW Process chains are a workflow capability for sequencing data processing steps within SAP BW such as index management, PSA/ODS load, cube load, statistics and aggregate creation.

• SAP Portal provides a capability for creating a workflow on the fly – it is SAP Portal Ad Hoc workflow capability. This feature allows the portal user to have better collaboration experience such as document proof reading and approval from other team members.

Considering the richness of the SAP product suite, there will always be workflow capabilities that are best suited for the specific product set.

Based on our experience, we recommend the following products for your workflow requirements:

• SAP BPM for UI centric business processes
• SAP PI BPM for cross-system business processes
• SAP Workflow for workflows within the SAP instance

As always, use SAP SOA based interfaces for all interactions between SAP systems.

At a high level, the various SAP integration approaches are: File, Database, SAP RFC, SAP IDOC and SAP web services. The file and database are not specific to the SAP platform, and are a very common mechanism for data exchange. However, they suffer from latency issues, and are suitable for large data transfers or where the connecting application has rudimentary integration capabilities.

The SAP RFC and SAP IDOC have been the traditional means of integration. SAP RFC is suitable for request-response style of communication. SAP IDOC is suitable for bulk data transfers (10MB and larger message sizes typically). The SAP RFC and SAP IDOC are compatible with the oldest SAP versions, and they are a safe approach towards SAP integration for guaranteeing backward compatibility.

The SAP recommended integration mechanism is to use web services. These web services can be implemented and exposed by the SAP platform which can be easily invoked by the non-SAP application for request-response or data exchange. The web service support is fully supported in SAP ECC6. The web service support is weaker in the earlier SAP releases. However, most SAP customers are in the process of upgrading to SAP ECC6 and we should adopt the web service approach towards integration with the SAP platform. It can be safely assumed that most customers would be at SAP ECC6 release to make use of the web service based integration. This approach complies with the best practices and integration approach recommended by SAP.

Understandably, customers have hesitation and lack of clarity on how to work with their service provider for remote SAP consulting services. Customers would tend to pay higher to get local SAP consultants rather than “try” this new method of getting SAP development and support services.

There are challenges of timezone, language and the absence of physical face-to-face meetings which are the immediate concerns of any customer. Many service providers are located in India, and they are several hours ahead of the customers in Europe and the Americas. The consultants are fluent in spoken and written English, and have exposure to major European languages. We are able to address these challenges through hiring of local consultants that interact with the customer locally. Our teams work on flexible hours to match the working hours of the customer; we use collaboration tools like instant messenger, screen sharing and video conferencing.

Many large customers have been operating internally across their distributed global offices, and they are comfortable operating across languages and timezones. SAP AG, for instance, has the development teams distributed across Walldorf, Germany and the development centers in India and other locations.

Many mid-size SAP customers in the USA and Europe are now seriously considering the option of remote consulting and remote support development due to the access to expert SAP skills and compelling cost advantages. These SAP customers are the mid-size organizations that have traditionally used the local SAP consultants; they are now reaching out to SAP service providers to start a pilot for remote consulting and remote support services.

Conclusion

SAP remote consulting has challenges but it is a practical and cost effective option for getting effective and dependable SAP services. Many SAP customers are able to develop a deep partner relationship with their service providers. SAP customers should attempt to make use of this remote consulting service to complement their existing SAP service processes.

As part of a company-wide upgrade to the SAP platform, our SAP Consulting team is using the SAP Netweaver ™ platform, SAP IS-Banking and numerous other SAP technologies to help catapult Patrimonio Hipotecaria to the next level of success. Our team will create a 12-fold increase in overall system capacity for Patrimonio Hipotecaria –while improving the consumer experience as well as streamlining internal efficiencies.

You can read more about this new customer engagement in our recent press release and new customer case study.

What is SOA

Service Oriented Architecture (SOA) is a software design strategy in which there is a service provider and many service consumers. SOA is similar to the distributed computing principles of loosely coupled architecture. SOA differs from the traditional client server architecture in terms of distributing the functionality over separate business objects exposed through service interfaces, loose coupling through independent business objects, durable interface contracts and promoting reuse of functionality through a loosely coupled architecture.

What is a Web Service

A web service is an interface implementing the industry standards of SOAP and WSDL (and usually HTTP) to expose functionality to a web service consumer. It is a technical implementation to expose functionality through a standards based protocol.

The use of web services has enabled a tremendous leap in enterprise integration. Till a few years back, most applications provided proprietary or rudimentary methods of integration, such as SAP provided SAP RFC, BAPI, IDOC based integrations. Such integrations warranted the use of middleware adapters to provide integration with SAP.

The use of web services now allows a direct integration between applications with the SAP business suite.

Hence, we recommend the usage of web services as a central integration strategy for all integration initiatives.

With the proliferation of web services, it is a challenge to catalog and manage the usage of services in the enterprise. Hence, SAP has provided a robust set of SOA toolsets to manage the usage of services in the enterprise.

What is an SAP Enterprise Service

An SAP Enterprise service is technically a web service, and it has the following attributes:

• Based on web services standards of WSDL and SOAP
• Based on SAP global data types
• The service has been modeled within SAP ESR using business objects, process components and the SAP enterprise model
• Published in the SAP SR (service registry)
• Guarantee on the availability and functional correctness

What if my Web Service does not qualify to be an Enterprise Service

There are scenarios where the web service interface exposed by an enterprise application is not globally relevant, and is really a technical interface to a localized business functionality. The usage of such a web service may be limited to the department in the organization and its particular IT applications having its own semantics.

Such web services are not Enterprise Services. However, SAP SOA tools can be used to manage and catalog such localized and non enterprise services as well. The SAP SR provides rich taxonomy capabilities to catalog and manage all such services.

Summary

Web services should be the central integration strategy for all integration initiatives to provide a standards based integration to applications. However, not all web services are meant to be used at an enterprise level across the organization.

The SOA Governance body should approve all enterprise service candidates based on the above mentioned criteria, and use the SAP SOA toolset for cataloging and managing all service in the enterprise.

Often, there are issues related to:
- Having a full time SAP consultant to address a functional area where there are few support requests or development requests
- Having a SAP consultant to manage and juggle many different functional areas. This leads to SLA issues when many issues pile up simultaneously
- Unable to address complex issues due to high costs involved in getting a Senior SAP consultant to the customer location
- Unable to implement advanced SAP modules (such as SAP APO) due to lack of inhouse talent for current and future support needs for these advanced modules

For all the above reasons, the customer organization continues to stick with the current implementation and the older SAP releases, and unable to innovate or implement advanced SAP products.

Remote consulting is catching up with many customers to address all the above issues.

Remote consulting allows you the following benefits:
- Access to advanced SAP skills and SAP talent. It is a fact that many Senior SAP consultants are unable to travel as much as they would like to! Hence, many Senior SAP consultants are constrained to serve their local geographic areas only.
- Cost reduction and control of SAP support budget. Remote consulting is always significantly cheaper than calling the Senior SAP consultant to physically arrive at our offices.
- Access to SAP functional services on Fractional basis. Many SAP service providers offer SAP services at less than full time basis. This is valuable for companies to get support for SAP services that have less support requests.

Today, many customer organizations are becoming receptive to the idea of SAP services delivered remotely. For many large global organizations, they are already geographically distributed over multiple locations and timezones and collaborating over the phone, Webex and VPN. For most organizations, remote consulting fits seamlessly with their current SAP team. Considering the advantages of access to sparse SAP talent and huge cost advantages, SAP remote consulting is the smart way to get access to SAP talent.

In this blog, we would present guidelines and best practices for usage of SAP PI in an Enterprise SOA environment.

Usage of SAP ESR and SAP SR for managing enterprise services:
- SAP ESR and SAP SR should be used for modeling and publishing enterprise services in the landscape.
- SAP ESR and SAP SR are provided by SAP PI and SAP CE infrastructures. Hence, the customer could install either SAP PI or SAP CE to get access to the SAP ESR and SAP SR instances.
- SAP ESR should be used to model and manage all SOA assets. We can use it to model SAP and nonSAP services. SAP ESR models can be used to directly implement the service implementation in SAP. With SAP ESR model, it is not possible to directly implement a .NET or J2EE service. However, the .NET or Java service signature can be made to conform to the Service definition described in SAP ESR.
- Enterprise Services Repository used to define re-useable services rather than classical interfaces
- SAP SR can be used to manage the publication of SAP and nonSAP services.

Usage Scenarios of SAP PI:
- All web services and enterprise services that are being exposed to the customer should go through SAP PI. This is to ensure scalability, security and availability, since going through a managed middleware ensures the quality of service (QoS) for the enterprise service. For example, we cannot expose an application web service directly to a customer in a B2B scenario since the security and load are unpredictable
- SAP PI is used to create abstraction between heterogeneous sender and receiver systems based on SOA standards to provide unified access to legacy systems.
- SAP PI 7.1 is for mainly leveraging functionalities for service enablement, and service and process orchestration
- Integration between non-SAP system and non-SAP system.
- Use SAP PI for both A2A, B2B integrations including EDI
- Use SAP PI for service enabling legacy applications that lack a framework for exposing web services.
- For SAP PI 7.1, many SOA enabling standards or WS standards are supported as part of this release making it the core technology enabler of Enterprise SOA. (e.g. WS Reliable Messaging, WS Security, SAML, WS Policy, WS PolicyAttachment  etc.)
- For a predominantly SAP landscape, SAP PI should be the strategic integration platform and the enterprise wide service bus

When not to use SAP PI in enterprise SOA:
- Recent release of the SAP platform (SAP ECC6) has native capability to expose enterprise services. The service should be modeled in SAP ESR and implemented in SAP ECC6. This service is readily available for consumption across the enterprise without the intervention of SAP PI or any other middleware.
- SAP PI usage is not recommended for synchronous communication since it places a significant load on the infrastructure services for servicing a synchronous request. Also, SAP PI cannot guarantee the QoS and response time in processing a sync request.
- For User Interface scenarios (such as a WebDynpro UI), the UI can directly consume enterprise services. SAP PI should not be used in UI driven scenarios if the backend is exposed as enterprise services.
- If a nonSAP backend such as .NET or J2EE or any other platform is exposing business services in a UI scenario, SAP PI is not needed for intermediation. The UI such as SAP Portal based User Interface through various SAP NetWeaver technologies (SAP CAF, SAP BPM, WebDynpro etc.) can directly consume nonSAP services.

In conclusion, SAP PI should be the strategic integration platform in a SAP centric landscape. However, SAP PI should be used as an intermediary if it adds value between the sender and the receiver entities.

So far so good. With increasing globalization of the customer base, we are witnessing several movements that are making the ISVs to sit up and take action to preserve their market share. First of all, the customers themselves are getting acquired by larger companies, and “acquiring” globally recognized names. The decision making policies are now getting centralized, and all decisions need to adhere to “global standards” such as compliance of new software products, interoperability, multilingual multicurrency support etc. Additionally, the ISVs are seeing increasing competition from the larger “less specialized” players who are coming up with offerings to compete head-on with the ISVs. Finally, the customers are now less excited about buying “best of breed” applications, and leaning towards solutions from a single product vendor which complies to their global IT standards. For ISVs, deep functionality is not enough to break into larger customers who have a certain gate-criteria for qualifying all software solutions.

SAP is the predominant ERP globally; it is run by a large number of global corporations across Auto, High Tech, CPG, Retail, Chemical, Pharmaceutical, Oil&Gas etc. These global corporations have acquired global footprint across Americas, Europe and Asia with distributed IT management teams. For consistent management, most corporations mandate SAP compliance of all software solutions.

For an ISV looking to break-into the SAP customer base (which consists of a significant number of Fortune 1000 companies), it is almost mandatory to demonstrate SAP compliance. SAP compliance would be one of the earliest concerns to be brought up by the IT during the product evaluation and due diligence phase.

Then why wait ?

SAP compliance can be achieved through the following two approaches:
- Migration of the product’s important features to the SAP platform: Though this may seem like a more difficult approach, it is not. We have helped customers to rapidly build important features of the product using the SAP NetWeaver platform in a short span of a few weeks. The initial product release is adequate to support the ISV Marketing team to start socializing with the SAP customers.
- Integration of the ISV product with SAP: This is a common approach to integrate the ISV product with the SAP business suite. We typically use SAP PI (SAP XI) middleware platform to provide data conversion between the ISV product and SAP proprietary data formats.

Finally, nothing beats SAP Certification! An SAP certified product or SAP certified integration provides assurance to the customer that the deliverable meets SAP’s quality and data interoperability standards.

How do we do it ? ISVs are understandingly not SAP experts. The best way is to partner with an SAP Services provider who has previous experience in working with ISVs and has completed several such projects. The ISV should not need to learn SAP or get into the nitty-gritty of SAP Certification, all these activities are the responsibility of the SAP services provider.

What would be the effort ? As with any IT project, we need to set the boundaries and scope of work to reach the effort and costs. As a rough estimate, an ISV can achieve their initial goals through a 3 month project with a 3 person team; With capable SAP expertise available offshore, the offshore costs should hopefully justify an SAP migration project to make it into your engineering and marketing budgets for the next quarter.

An SAP NetWeaver project would typically consist of identifying new business processes to be implemented, new SAP BW reporting, new data integrations etc. The SAP Netweaver is a platform that provides implementation of new processes and data visualization applications where the SAP ECC is at the backend. Hence, the need for SAP ECC core configurations is minimal.

As with any development project, the initial phase of the project needs close understanding of business requirements. This requires the Business process consultant to personally interact with the business and identify the business requirements through workshops, white boarding and discussions over printouts/charts/sheets etc. This process typically takes 10% of the total project effort for capturing the high level requirements. This phase of the projet has to be conducted onsite to fully interact with the business and understand their true requirements and aspirations.

Thereafter, the next level of details can be arrived at by the remote development team located at the offshore location. This includes creation of mock User Interface and mock process walkthrough to confirm the requirements. This is a partial development activity and can be efficiently conducted offsite. All artifacts can be discussed with the customer team remotely, with the partial assistance of the onsite consultant. This activity may take about 20% of the total project effort.

Thereafter, the design and development phase of the project can be totally conducted offshore. This phase takes 40% of the total project effort and needs access to deep SAP Netweaver expertise. We do not need close co-ordinatation with the business for this phase. Hence, this phase is ideally suited for offshore execution because it needs access to deep SAP Netweaver expertise and can lead to significant cost reductions for the customer.

The object is unit tested, and then provided to the customer for integration testing and acceptance testing. Thereafter, the approved objects can be deployed to production. All these activities take the remaining 30% of the project effort.

As we can observe, the initial phase of capturing high level business requirements needs an onsite presence to determine scope and negotiate with the Business to reach a technically feasable and cost-effective solution. Almost all the remaining activities can be efficiently conducted offsite to leverage the team knowledge and SAP Netweaver expertise available in the offshore team.

In our direct experience, we are observing customers to benefit through SAP NetWeaver offshoring by getting access to Netweaver experts located at offshore locations, and also get cost savings due to lower cost offshore pricing. This lives up to our motto of doing the “right activities at the right location”.

With our expertise in software product development, manufacturing and SAP consulting, we knew Nagarro was a great fit for QISoft. But the winning the business was only the beginning. The real success story here is that Nagarro is making an immediate, positive impact on QISoft’s long-term competitive advantage.

In today’s dynamic business environment, IT departments need to remain agile so they can align IT strategy with shifting business,market, competitive and economic conditions.  Outsourcing is one way to adapt resources to suit an ever-changing landscape but can also introduce risks if the right partner is not engaged or the partnership is mismanaged.

Companies rely on SAP deployments to run their core business operations.  As a result, outsourcing decisions must contemplate security controls and allow the IT department to maintain operational control.

In an effort to help you identify and manage risks, Nagarro’s new white paper addresses some common outsourcing concerns and objectives, and provides practical information that can help you more effectively address your current and future business requirements.