Software Development, of course, is kind of creative work, but nevertheless, it is an industrial process. That means, this process can and should be monitored and estimated. Furthermore, software developers management can learn much from the industry in terms of quality management. An ABAP based application is a product, which has to be purchased, planned, developed, tested, sold and maintained. Technological progress has to be used, to improve the SAP-based applications and – not to forget – to boost the sales and the revenue of the SAP Competence Center.

The reality in most SAP running companies is far away from this. Although the IT department has been outsourced to IT subsidiaries (which means: they have to sell their own products to the functional departments, which are their customers), they don’t treat their SAP applications like they should handle their product. I shocked some of them by using the statement: “If you’d build your enterprises’ main products as you develop tour SAP applications, you would be bankrupt a long time!“

Gil Amelio, a former head of Apple Computer, made the following statement:

"Apple is like a ship with a treasure, leaking water, and my job is to point this ship in the right direction!".

Applied to the attitude of many SAP running companies, they behave similarly.

The SAP system is the collection of all business processes in a company, therefore it is a treasure, which values lots of money. Undocumented processes are worthless because they can not be improved or changed. Imagine, a company like Apple does not have any documentation of the technical details of their iPhones. „Steve knows that we can ask him“ is a bad answer – not only when Steve dies, but also when he leaves the company, he falls il, is on vacation, etc.

There are masses of books, how to do product lifetime management with SAP, and (knowing, that all general statements are wrong) no one does this within SAP. SAP PM provides many features for product maintenance administration, but it’s not being used by the IT companies, which are running SAP systems for their customers. They do not even implement a ticket system in most cases, because of the effort! This calculation is as wrong as the statement „I do not have any time to clear my desk“ (a clear desk is a very underrated timesaver!).

How far would you trust a company, which does not use their own products, they want you to buy? How far would you trust a consultancy, creating your business processes, which does not have any for their own business?

The reality is: Users do their incident notification via phone, specifications do have the size of a beer coaster, the testing process is just trying some use cases (mostly just one), documentation won’t be written, and so on. This may sound horrible for engineers in car or plane construction or any other branches, but this is the reality in their own IT.

The most impacting improvement are standards. Standards for specifications, coding standards, documentation standards and standards for the whole development process itself as well as for the incident handling and emergency plans.

Now that we can figure out, where we wanna up to, let’s talk about the options for improvement. Let’s define an application lifecycle, which could fulfill the requirements of the 21st century. And, yes, you will tell me, that it’s too expensive and consuming too much time. But you won’t get your car to a garage to repair the brakes, because they are fast and cheap, just because their employees do not work like a professional and they do not have any test efforts. We are professionals and want to develop high-quality applications, running fast and secure

• From requirement….

  At the beginning of each software application, there is a requirement. In most cases, this requirement is detected in the functional department. The first failure, which can be made, is deeply enrooted in the one-dimensionally understanding of the business process itself. Each business process works hand in hand with others, a company’s success is the result of interaction within the business processes’ network. This means: You can not define or modify a business process by blending out other processes, even when this is processes of another department. The module centered view to an SAP system is outdated, we have to come to a business process based view, across multiple departments and multiple subsidiaries, multiple companies, including the requirements of distributors and customers. Lack of seeing the big picture is the most order reason for crippled business processes, multiple copies of similar or even the same applications in one SAP system.

• …via functional specification….

  After design of the business process and the interplay with others’, it has to be described in a functional specification. This specification is self-contained, which means, that a requirement, which not has been described in this document, has not been ordered! The requesting department is in charge for the completion of all requirements because modification the business process can result in a complete redesign of the resulting application. But this document is not only describing requested features but unwanted features as well! Most of the security-related bugs in an application are caused by coding, which fulfills the requested features, but undocumented other features as well and most of them are unwanted.

• …and technical specification…

  After this document has been written and approved, the SAP Competence Center has to do the effort estimation in cost and time. In detail, the developer has to talk with the related functional consultants, on which way this business process can be implemented into the system. The result is a technical specification document, which describes, how the application has to be built to fulfill this requirement, including all testing and documentation efforts. In some cases, the result may be a reference to a standard application, which has been delivered with the system itself, which results in a user training document instead if a technical specification. To make sure, that this estimation consciously and accurately, there should be a standard budget for this kind of work, i. e. 2 man days, to be paid by the requesting department. We shouldn’t forget, that each employee has to report his productivity to his manager!

  Of course, there is another way to get to a functional specification. In terms of sales promotion, the SAP Competence Center has to offer business process improvement suggestions to the functional departments. But this is another story.

  Let’s inspect the case, that a new application has to be designed or an existing has to be enhanced. The technical specification, which shows screen mockups as well as database table descriptions and all other details of implementation, has to be sent to the person in the SAP Competence Center, who is in charge for quality management and software logistics. This person has to have a general overview of all over the system – the big picture – and has to check the specification for already existing development objects. There are many SAP systems, where multiple classes customer are existing and this person has to avoid side effects like this. His suggestions are to be considered.

  This final technical specification has to be sent to the requesting functional department for approval, which results in the development order (or in a rejection, of course). This approval phase has the same significance, last orders, please has in a British pub: From now on, no changes or enhancement of the order is possible. It tells the SAP Competence Center: Do that as described in this document!

  But there is another reason for being of this document: It is the major part of the documentation, whose delivery has to be part of the application's going live. In Germany, a manufacturer has to deliver a German end-user manual weird each B2C product otherwise, the customer can reject the product and has to get his money back, regarding German law. This applies for televisions, smartphone devices, and eBook readers, but not for SAP based applications, because the customer is a company. This does not unravel the mystery, why this kind of customers does not stipulate a documentation. We know how that works results into legacy coding if the knowing employees leave the company an often seen effects like this: There is an application, which implementation details no one really knows! Consider the employee Steve, I talked about earlier!

• …to implementation’s beginning!

  The first step to increase the application’s quality is the way, the developers write their coding. Most of the developers may think, they write their coding to feed the ABAP compiler. Perhaps they are of the opinion, that they have to write coding, which they can understand by themselves. But the other side of the coin is underrated: A developer has to write the coding in a way, another developer can understand! A developer with another background, with no special knowledge about special business processes. This is the reason, why coding comments have been invented! A professional developer comments EVERY NON-OBVIOUS CODING SEQUENCE! Each non-obvious context relation has to be explained. The very most important reason for this requirement is: The company owns the coding. The company owns the business process definition. And the developer is in charge to enable the company to transport this knowledge (which it has payed for!) from one developer to another. This requirement is easily overlooked by most of the SAP developers.