An organism like your SAP system can evolve and adapt to its particular business jungle. Become faster, more efficient and make users happier. It requires you to be bold, to stay safe but assume the risk.
This evolution should be the next step after a successful implementation of a basic standard platform. This is the logical thing to do. Like starting building the house after the foundation is set. Yet, you see everywhere cautions words about customization, portrayed as something to fear, a last resort option. Progress becomes a steady succession of upgrades and support packs that offer not much improvement over what you already have.
I’m a pro-customization consultant and this is the manifesto of my beliefs. I believe constant improvement techniques should be applied not only to your processes but to your system, finding new ways to help users do their jobs, supporting those characteristics that make your business particular and competitive. The blog that this post starts will explore customization ideas and projects in production planning in the hope to attract like-minded professionals and maybe converting a few nonbelievers.
SAP aims to be a platform for any industry. By adjusting its configuration it can cover many requirements and adjust to most processes. There is however a limit to what standard functionality can accomplish. The indication that SAP knows its own limitations is the wide range of customization options it offers. Its source code is there for all to see and it lets you ABAP your solutions in many ways. The list is long: user exits, BAdIs, coded queries and programs of all kinds as well as standard functionality with code-like flexibility (e.g. object dependencies in variant configuration).
We can also consider as customization the use of standard functionality in clever ways for which they were not originally intended.
There’s a place you rather be. I exhort you to step beyond the line, unmask the ghosts by the road, plan for ambushing bandits, and get on your way.
Ghosts, bandits and the NO-NO policy
Ghosts are unsubstantial characters in horror tales used by those who want to keep you boxed inside the standard functionality for their own reasons.
Depending on their role these people will suggest or impose a NO-NO customization policy because:
- They don’t know how: Consultant tend to reuse approaches that has been successful in the past, functionality they know in detail. In addition to knowledge shortage, they may lack the willingness to search, learn and try a different way.
- It requires more work: To customize you need to think and test different options and occasionally be sent back to the drawing board by the unsuitability of an idea. Maintenance is also harder than with standard functionality.
- Plain is more profitable: A lot of recycling is possible, when doing a customer after another, if standard functionality is used. Much can be saved by copy-pasting documentation. Firms can do standard implementations with cheaper consultant with little experience while customized solutions require time from their high value gurus.
- They want to cover their backs: Risk is ever present in any implementation, but blame can be diverted to SAP when the solution is standard. Customizing requires you to assume responsibility for your decisions and actions.
You should not be afraid of ghosts. Use your time instead preparing for real bandits.As with any myth, there are aspects of truth that you should be aware of, real problems that you should plan for or situations where customization should be better avoided.
- Upgrades: Upgrades are SAP changing the rules of the game and that causes a lot of problems. This is true even for standard functionality but bad, as in fragile, customized code can be particular sensitive as it is your job to test it and adjusted for SAP changes.
- Standard functionality can cover it: Do not reinvent the wheel. Check first if an off the shelf functionality can do it. Something you have not used before, even obscure.
- There is no need: It is frustrating to invest money and effort in a tool that no one uses because the need is not real, the solution is too complex or the benefit is not realized.
- Zombie systems: The worst use of customization is to keep alive reports, screens and procedures that should have died with the legacy system. This happens when users are unwilling to incorporate the best practices on which SAP is built on – or even try a slightly different way to do the same thing.
- They don’t know what they want: When first implemented, users don’t know what SAP is capable of or its limitations. They may ask for things they don’t need, things they won’t use or figures that cannot be derived from the data in the system no matter how much you play with it.
These are valid reasons to treat customization with respect. The way you should treat electricity even if you wouldn’t consider adopting an Amish lifestyle because of the potential danger.
Step Beyond
There is a right way to do customization and you can archive it by following a few guidelines including these:
Embrace customization: If you fear customization you will shun from it, will not dedicate the time and effort required and the result will be a half-baked solution, fragile and dangerous, that will bite you back when less expected. Give customization the importance it should have, invest time and people in it, design procedures and rules to produce valuable and resilient solutions to be proud of.
Assume the risk: Life is risky, SAP implementations are risky; manage it. Even the most standard of systems will have some risk – it can fold down your company by not being complex enough for your needs. The solution is not to dodge customization but to be prepared. Most of the points that follow will help you reduce the risk or recover from an adverse event. Eliminating risk completely is unrealistic.
Determine the real need: Some customization undertakings start with the wrong foot by jumping to the solution without properly defining the requirement. Users are particularly bad specifying what they want. Uncovering the real need behind the request is fundamental to deliver a value added solution that the user won’t abandon. The distance between users and programmers introduced by outsourcing has contributed to the proliferation of spec perfect solutions nobody uses. Analyst should be capable to challenge the users in order to give them not what they want, but what they need.
Sell it: You should be so proud of your solution to brag about it; or at least to sell it to others with confidence on the advantages it provides. Why don’t use the tested tools of marketing: surveys, focus groups, promotion during training and post implementation customer service? Make sure that a good idea doesn’t go to waste because people do not know about it. The upgrade should be optional when possible, so the user make the decision to use it because they see the benefits. This also forces the IT team to make sure that the customization has a real value that can be measured.
Get it stable first: Customization during the initial implementation of the system is necessary to adjust the system to business specific processes that are fundamental and the standard cannot support. It is however preferable to let the system stabilize for some time before starting to incorporate further enhancements, allowing the business to understand better what the system can give them and what they lack. Incremental steps giving time for the new features to get assimilated are better.
Document for maintenance: People don’t read documentation, so make it readable. As with any form of writing documentation should grab the reader attention and express ideas clearly. Don’t write to yourself; don’t assume the other knows what you do. Always start exposing the origins and the rational of the tool, selling its benefits and warning about known issues and limitations. Leave the technical details to the bottom of the document. Having the original document with changes appended at the bottom is a bad idea, it makes understanding the document a torture. Use versioning to keep track of history but keep the main document as a consolidated view of what is currently there. Make parachuting into the project easy for newcomer consultants and users with a central compilation of all the customization in the system with a link to each feature’s document. Use technologies like Wiki to let anyone expand or correct, rearrange and link what becomes no longer documentation but a useful reference and help tool.
Code for maintenance: Always choose readability over performance. People may complain about speed but it never reaches the level of hysteria caused by a problem that is taking time to fix. Segregate every step in blocks or function calls (extract_data, do_calculation, display_report). Put additional effort while commenting the code, using several lines for each step to explain what it does and the logic behind it. Make the code your main technical document.
Use resilient code: Fragile code is the result of rushing things, bad practices and poor understanding between analyst and developer. Fragile code fails during upgrades or if a special case is encountered, failure is usually unexpected, catastrophic and difficult to fix. Resilient code fails too but knows how to fold graciously instead of exploding and falling in flames. Suggestions of good coding practices – like checking if a number is zero before dividing by it – require a post of their own.
Leverage your team: Don’t allow the consultants to leave your people in the dark, make sure that the understanding of the details is passed to your team, that they make it their own. If you team is not capable of owning the solution, develop them. In particular, I believe that the most effective investment you can do in training is to teach your analysts enough ABAP to read and debug code, write specs for solutions that are feasible and discuss on the same level with the developers.
Make your customization configurable: Create a table for any new piece of code with an indicator that you can set or reset to activate the code or skip it; either as a global switch or dependant on a group (a plant, a material type, an MRP controller). If you code allows for different approaches let the configuration table define which. Avoid hardcoding, use a customized table or a selection parameter instead. By configuring your customization you can activate the functionality just for a pilot and then roll it over in a controlled way. This also allows you to easily fall back to a previous version, or all the way to the standard, in case there are problems.
Test, test, test: It cannot be stressed enough, you should test as much as possible as many cases as possible. But also understand that real testing only starts when you move the solution to you production environment. Do not be surprised that the business has issues with your solution; you should be in alert and ready to act. Ask for feedback and adjust the code as soon as the need arises.
So these are the precepts that I have based my career on and that guide what I currently do. They are also the basis of this blog where I will promote customization by sharing ideas and giving away solutions that you can useand expand.
M. Night Shyamalan’s film “The Village” shows how people can feel a moral duty to make you fear what they fear, to keep you away from danger. You can however have a different view. Stepping beyond that line can take you to a whole new world of opportunities.
(This post was first published on the author's professional blog, see profile)
- SAP Managed Tags:
4 Comments
| User | Count |
|---|---|
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
