Understanding “Managed Services” from multiple perspectives
More and more organizations are realizing that while “IT” forms the backbone, they should focus on their strong area – namely the business and leave IT in the hands of the IT service providers. This approach of “IT Services” trend is enabling organizations to focus on “CTB” (Change-the-business) rather than “RTB” (Run-the-business).
The change can be “felt” at all levels – for example, earlier when doing product evaluations / comparisons, I gave elaborate comparisons (read graphs and pictures!) and opinion influencing the decision but left the final decision to the Customer. Now the customer expects and more importantly accepts that the consultant would make the decision and give the next steps to be taken – either product shortlist or a product PoC or a selected product implementation to go ahead and use the underlying data only to justify the recommendation.
The concept of “Managed Services” has been making steady progress for the past 4 to 5 years driven by the “IT as a commodity” trend. Economic factors, pressure on CxOs to show cost reduction, improving technology trends, long relationships with service providers (who essentially have been managing IT, though with less control and ownership) are some of the factors that pushed “Managed Services” to the forefront. Frameworks like ITIL, CMMI-SVC and standards like ISO 20000 serve as a means to ensure Service delivery capability. Continued »
Storing all the key business documents in one place is the key purpose of having an Enterprise DMS (Document Management System). Single Source provides benefits of easy retrieval, increased visibility, one set of rules for managing documents, better control of documents. While Storing documents, store suitable attributes also to fulfill search requirements.
SAP provides an enterprise document management system, SAP DMS that can be used to manage documents for the entire enterprise business. SAP DMS (Document Management System) is a cross application component of SAP ECC that provides robust document, content and digital asset management capabilities. DMS is powered by SAP NetWeaver.
If you have invested in SAP DMS, then there are sufficient reasons for using SAP DMS as the Enterprise DMS: Continued »
SAP Business Workflow
SAP Business Workflow can be used to define simple release or approval procedures, or more complex business processes such as creating a material master and the associated coordination of the departments involved. Workflow is used for automation of business processes in turn reducing manual work and enabling monitoring capability.
SAP Business Workflow is particularly suitable for:
- situations in which work processes have to be run through repeatedly, or
- Situations in which the business process requires the involvement of a large number of agents in a specific sequence.
- Situations involving responding to errors and exceptions in other, existing business processes.
The workflow mainly involves:
- Events – Events are created to report status changes for an application object and to allow a reaction to the changes (e.g., Material XYZ created). These events can be used as triggering events for your workflows.
- Tasks – A task contains a task description and the connection to the application logic via the method for a business object (e.g., Create Purchase Order). To use a task productively, you must assign the tasks to its possible agents. For differentiated control, the SAP task and customer-specific task can be used.
- Object – Workflow routes the document among different persons who perform certain activities and the goal of the workflow can be put inside an object type. An object can be considered as a structure with certain data and some logic (e.g., FORMABSENC is an object in SAP that can be used for the notification of leave).
- Business Workplace & Work Item – Business Workplace is a work area that an SAP user can use to carry out business Processes. For example, the inbox can be the workplace in which the manager receives the request. The request that the manager receives in this inbox is called a WORK ITEM. The manager can open it, check the details and approve the same.
- Agent – An Agent is a person who executes a work item (e.g., the manager who approves the request).
In essence, workflow can be summarized as:
- Workflow engine automates business processes.
- Workflow can be triggered by an event.
- Workflow definition consists of a sequence of steps.
- Each step can be an activity (or a task). Task in turn refers to a method to implement a specific logic. Steps can also refer to user decision, and other programmatic controls.
- Runtime representation of the step is called a work item. This work item sits in the inbox (business workplace) of the responsible agent assigned to the step.
- Agent determination can also make use of Rule.
A simple and excellent document titled “SAP Workflow in Plain English” is available at http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40a1a7ab-dcd5-2c10-63aa-9bc68b42e1f9?QuickLink=index&overridelayout=true.
SAP provides several workflows that map predefined business processes (e.g., Release a purchase requisition). SAP workflow automates the business processes (e.g., “leave application approval”, “place purchase order”) and can be used as cross application tool across various modules of SAP. The SAP workflows can also be used as templates for new workflow developments.
Effective use of SAP Workflow enables the incorporation of your enterprise specific business processes (approval hierarchies, business rules) along with the world-wide established best practices which the ERP tries to bring in place.
SAP NetWeaver PI as Enterprise Service Bus (ESB)
SAP NetWeaver Process Integration (SAP NetWeaver PI) provides SOA foundation capabilities for SAP customers. SAP PI is an integration platform that provides seamless integration between SAP and non-SAP applications inside and outside the corporate boundary.
SOA enabling standards (WS standards) are implemented in SAP PI 7.1 making it the core technology enabler of SAP Enterprise SOA. The essence can be summed up by what a customer has said – “SAP NetWeaver PI 7.1 is now a true ESB”. Continued »
After a long debate on SAP vs Oracle, SAP was chosen as the ERP for a Microsoft-centric organization. The following are the points used to build the business case for SAP:
SAP has depth of Features set and software functionality; SAP Functionality is hard to beat; (Gartner, Forrester, Customers, ERP Asia, ERPFacts.com, TEC – Technology Evaluation Center)
SAP as a brand carries weight as the company is a global leader and benefits from over four decades of building and supporting sophisticated business applications. SAP continues to focus its ERP applications on maximizing resources and reducing costs that are customized for businesses and industries. SAP has evolved its applications to have very deep industry focused solutions. Continued »
For a client who has decided on going the ERP route, the product selection (SAP vs. Oracle debate) was dragging on for almost a year with intensive debates between supporters for both products. The result was more of a deadlock as clearly both products were equally capable and also equally expensive and difficult to implement.
The two factors that influenced the choice were:
- the Client was an out-and-out Microsoft shop – in terms of products as well as skills available
- SAP was the ERP used by its parent company and some of its sister companies – though there was no plan for consolidation or even integration, the availability of experts in the group is seen as a plus
The following are the factors the basis of the decision:
- SAP and Oracle did not differ functionally or even in non-functional characteristics in any significant manner (Gartner, Forrester, Customers, ERP Asia, ERPFacts.com, TEC – Technology Evaluation Center)
- From ease of use perspective also (based on the product demos, the business users felt that Oracle had an advantage here), according to Gartner report and ERP forums Oracle is as difficult (or easy) as SAP.
- Oracle is found to be slightly technically superior solution – achieved by exploiting Oracle as the Database to the best possible extent. But Oracle Database skills are not available within the company and when proceeding with a major ERP implementation this could turn out to be a unnecessary risk taken.
- Oracle Fusion to be delivered in 2013 being the focus of Oracle, the product roadmap for Oracle ERP is not clear
- SAP and Microsoft have an excellent relationship as shown in the SAP benchmarks, Duet initiative etc. SAP integration with Microsoft platform is very good – and makes sense in the context of Microsoft shop that heavily uses MS Office, Outlook, Share point etc.
In the process of this decision making, collated details on SAP and associated products and sharing the same as individual blogs.
Established EA and EA Governance ensures effective Mergers and Acquisitions
Mergers and Acquisitions (M&A) are typically done with the objective of gaining particular assets and / or to gain to a new customer base. To be effective, it is necessary to carefully consider the operational ramifications and the potential business and technology issues bringing the two organizations together.
Forrester clearly points out that the key best practice in handling M&A is to “Use business and IT capability maps developed before an M&A to accelerate due diligence and planning”.
The typical problem faced when two organizations have to merge is in rationalizing their systems, especially so as each side tend to take a view that their systems and processes are superior. There are cases where a long time (a couple of years) is spent in comparing each and every system/application with their counterpart and decision taken on an individual basis. In addition to the time and effort, the end result tends to be a sub optimal one, as the decisions are taken at each part and not looking at the “whole”. Continued »
While most of the aspects discussed so far are related to online integration, it is worthwhile to mention that 80% of today’s integration relies on basic technologies like file transfers. File Transfer based integration though has the negative factor of High Latency, brings in lots of benefits and hence should be the preferred choice wherever possible.
File Transfer Make the data available by transporting a file – to any format like xls, csv, xml, flat file – that is an extract from the application’s database so that other applications can load the data from the files.
The plus points are:
- Local copy of the data exists – and high performance (for both applications)
- Maximum level of Isolation – each application can be independent of each other – and only communicate on a planned basis for data replication
- Security constraints can be enforced at file usage level
- More efficient as it is getting chunk of information at one go
- Can be used in both Push/Pull mode, depending on the business requirement
- Preferred for Updates – as the Validations and data integrity checks can be built in before bulk updates
The downsides are:
- High Latency – needs Latency Tolerance
- Data replication and Synchronization to be handled – if the communication is two-way
Other factors are:
- Isolation possible – using data transformation
- Need to have Simple Conflict resolution Logic – involving human intervention, if required.
- Medium Complexity to build
- Use Wherever possible – within the context of data integration
- Exploit application’s Import and Export facility
- Ideal if there is latency tolerance (if considered from pure business perspective, this becomes applicable in large number of real-life situations).
Service Oriented Integration
Service-oriented Integration (SOI) – a logical extension of functional integration – is where the applications integrate by using service interactions in an SOA environment. Service are provided by source application (service provider) and consumed by target applications (service consumers). Typically, SOI is implemented as systems that consume and provide XML-based Web services.
SOI addresses the issues of integrating heterogeneous and inflexible systems while overcoming the difficulties of functional Integration in terms of location and technology of the function. For example, functionality in a mainframe can be exposed as a web service implemented using a .Net framework.
In SOI, the service defines a contract – such as the technology, communications protocols, and message definitions – that all service consumers must conform to in order to communicate with the service. SOI enables loose coupling, thereby bringing flexibility and interoperability to newer heights – to the extent that the service provider as well as consumers need not be fixed – and the change in the service provider can be transparent to the service consumers.
In spite of its various benefits, Web Services using XML is not a panacea for all integration scenarios – as it involves considerable effort (for implementation) and overhead (during runtime). For example, usage of XML while providing maximum level of data independence does have a performance overhead due to transformations required.
Let us look at the W3 Definition of Web Services – “Web services architecture is an interoperability architecture that provides a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks”.
Web Service and XML make the most sense in case of Integration between Unknowns, applications running in heterogeneous environment, and applications that change frequently.
If the organization has application predominantly running on a single platform and hence do not have the complexities associated with integration between disparate platforms – which is chiefly addressed by SOI, using SOI makes most sense for integration with external world – web portals, other web sites etc. – where the flexibility and interoperability is most required.
If SOI is considered for integration of applications internal to the organization – as they provide the maximum flexibility and interoperability, use of Enterprise Service Bus concept and use of commercial tools is strongly recommended.
For basic information on SOA, Web Services and ESB, refer to earlier blogs https://itknowledgeexchange.techtarget.com/enterprise-IT-tech-trends/essentials-of-soa-web-services-and-esb-in-the-integration-context-part-i/.
Functional Integration – the logical extension of data integration – is where the applications integrate at the business logic layer by allowing the business function in one application (the source) to be accessed by other applications (the target).
Functional Integration is possible when:
- The function needed is available as part of source application’s business logic.
- The Application Programming Interfaces (APIs) is provided
For the APIs to be most effective, they should have been designed to be accessed remotely (Wrappers and Adapters can be developed if the function is available but not meet the API / remote access.).
If the applications only expose their business functions as a local API – and are also dependent on the programming language, then an adapter or middleware interface has to be developed to make it remotely accessible. Continued »