How easy are custom solutions for specific SAP industries?

Question

First of all, I have a very superficial knowledge of SAP. In my opinion, they provide a number of industry solutions . The concept seems very interesting, and I'm working on something similar for the banking industry. The biggest problem we face is how to adapt our products to different customers. Many concepts are very similar to enterprises, but there are always some customer-specific requirements that need to be addressed through customization and customization. Often this requires redefinition and development of customer-specific functions.

I wonder how effective SAP products are in this sense. How much effort does it take to adapt a product to meet specific customer needs? What are the mechanisms used (configuration, programming, etc.)? How can this be compared to developing a custom solution from scratch? Are they able to use and promote best practices?

Answer 1

Disclaimer: I am only talking about a piece of SAP software based on ABAP.

Disclaimer 2, PATRYs: HR response is slightly different from the rest of the SAP / ABAP world. I feel competent enough as a general-purpose ABAP developer, but programming on personal computers is so far from my personal beacon that I did not even try to understand what they were doing there. % - |

In my opinion, they provide a number of industry solutions.

They do - but be careful when comparing your own programs with these solutions. For example, IS-H (SAP for Healthcare) began as an extension of the SD (Sales and Distribution) system, but has since become much larger. Although you can technically use all the methods that they use for your IP, you really should ask a competent technical consultant before you do this - there are so many holes that should be avoided.

The concept seems very interesting, and I'm working on something similar for the banking industry.

Note that SAP for banking already exists. See http://help.sap.com/content/documentation/industry/index.htm for documentation.

The biggest problem we face is how to adapt our products to different customers.

I would rather rephrase it as "The biggest problem is to know where the product is likely to be adapted and to prepare the product structurally for adaptation." Adaptation methods are well studied and easily used when you know where the client can deviate from the idea of ​​an ideal solution.

How much effort does it take to adapt a product so that it meets the specific needs of customers?

This, of course, depends on the deviation of customer needs from the standard path, but it will not help you. When using an SAP-based system, you always have three options. You can try to configure the system within your limits. Setting up basically means setting up the settings (see Tables of configuration, tens of thousands of them) and adding material (program fragments, forms ...) in the places that are intended for this. Technology - see below.

Sometimes customization is not enough - you can develop things additionally. A very frequent requirement is some additional reporting tool. In the SAP system, you get the whole development environment - the same tools with which all standard applications were written. Your programs can coexist peacefully with standard programs and even use common procedures and data. Sure, you can really hurt things, but show me a real programming environment where you cannot.

The third option is to change the standard implementations. Modifications are like a really sharp double-sided kitchen knife - you could cook really cool things in half the time required by others, but you can do a lot of harm to yourself if you don't know what you are doing. Even if you are not really going to change the standard programs, it is very nice to know that you can and you have full access to the encoding.

(Note that this is only about application programs - you have no chance to configure the kernel, but, fortunately, this is rarely necessary.)

What are the mechanisms used (configuration, programming, etc.)?

Configurations mainly relate to configuration tables with more or less complex dialog applications. For the programming part, there is an extension infrastructure in the configuration - for more details see http://help.sap.com/saphelp_nw70ehp1/helpdata/en/35/f9934257a5c86ae10000000a155106/frameset.htm . This is basically a controlled version of dependency injection. As a solution developer, you must anticipate extension points, define the interface that should be implemented by the client code, and then embed the call in your code. As a project developer, you need to create an implementation that adheres to the interface and activate it. The basic runtime system takes care of gluing the two programs together; you have nothing to worry about.

How can this be compared to developing a custom solution from scratch?

IMHO it depends on which part of the solution is the same for all customers and how much it should be adapted. It is very difficult to be more specific without knowing more about what you want to do.

Answer 2

I can only speak for the Human Ressource linker, but it is a component where there is a big difference between clients, based on the general need.

• First, most of the time you set a value for a group, and then associate an object (person, location ...) with a group that depends on one or two values. This is similar to indirectness and provides more flexibility, since you can change the association for a given location without changing others. in several cases there is a 3-level direction ...
• Secondly, there are many settings that are almost programmable. For example, salaries or administrative operations are second to none. In the latter case, you will receive a table with the operation (hiring for example), an event (creating, changing ...) of the code for the action (I for the test, F for calling the function, O for the standard operation) and a text field describing the parameter parameters (" C P0001, begda, endda "to create a structure P001 with default values).
• Third, you can also use such a table to indicate a function or class (ABAP-OO) that will be dynamically called. You have a developer to create this function or class, and then indicate this in the table. This is a method of replacing a functional function with another or expanding it. It is used extensively in ESS / MSS.
• Finally, there is also a dot or extension file that you can modify. this is almost the same as the previous one, except that you do not need to indicate the change: the file is always used (ZXPADU01 / 02 for HR-modification of the infotype).

hope this help
Guillaume PATRI