The Problem

Securing credit card data in business systems can be costly and complex. And when you have multiple systems that use the credit card information, it becomes more complex. While some systems like SAP allow you to encrypt the data, if procedures are not followed, there can be glitches that expose the data (see previous articles for examples). And very few systems (including SAP) have an elegant standard system to track who accessed the data over a period of time.

A breach in security that exposed the payment card information can be extremely expensive as discussed before. And there is a very real possibility of people losing their jobs as a result of this negligence.

A Possible Solution

One solution I have seen is not to store credit card data at all or only store it temporarily. This is not ideal and can only work in certain industries. Even though the data is encrypted, all credit card data is purged from the system that is older than say 30 days. Not a great customer experience if the customer requests that you simply use the credit card they used on the last transaction. As your system is not designed for this, this is where credit card information suddenly gets written down and stored in desk drawers, simply to provide good customer service. That is just asking for trouble.

But what if we could use this idea of not storing the payment card data to achieve what we want?

A New Paymetric Solution

In August 2007, Paymetric announced a new product called XiSecure.  XiSecure comes in 2 flavors: an Onsite Server or an On Demand SAAS solution.

Basically it is a tokenization server. It removes the  credit card data from the business systems and replaces them with a 25 digit token.

A simple analogy could be a spreadsheet with 2 columns. In 1 column, we have all the credit card numbers and in the next column we have a 25 digit  number or token. There is a 1:1 relationship between the credit card # and the token. While the token represents the credit card, if you only have the token, you cannot do anything with it.

This spreadsheet represents that database in XiSecure.

How does it work?

1. It removes all credit card numbers stored in your business applications – such as SAP – and places them in a highly secure, centralized system that can be protected and monitored utilizing robust encryption technology.
2. It replaces the stored credit card numbers in enterprise applications with encryption tokens. These are unique tokens that reference the credit card number.
3. Should the business application experience a security breach, the token would have no value. This adds a new layer of protection against theft and misuse of credit card data.
4. It provides key management and key rotation capabilities outside of enterprise applications – Traditionally a pain.
   
5. It provides comprehensive access logging.

6. It provides comprehensive monitoring of decryption requests

Advantages

1. This solution makes PCI compliance much easier. Particularly if you use XiSecure On Demand solution.
2. As there is only a token in all your business systems, it is not necessary to encrypt the business data.
3. If you use an on demand system,  (such as XiSecure On Demand), you can focus on your core business and allow a 3rd party to focus on what they do best, ensure the security of your data.

Conclusion

Credit Card Tokenization can provide a simple solution to shield you from costly credit card data security breaches. I believe that the Paymetric XiSecure solution appears to be a viable solution that you should investigate in your business.

To be clear, I have not implemented the solution. However, I have worked with Paymetric’s XiPay solution and I was very impressed. As such, I suspect that this will be a robust and solid product as well.

The Big Problems

The biggest problem with processing payment cards (processing credit cards, debit cards & corporate buying cards) with SAP, is the integration with the payment card gateway or the bank. If you plan to develop your own, it takes many months of development. Then the interface needs to be certified by the financial institution to meet certain standards (different for different banks). At the end of the day, you now have this custom interface that needs to be maintained each time there is a change in the requirements. The question you need to ask yourself is: What is my core business? Do I really want to be in software development?

The Solution

Find a third party company that specializes in payment card processing and integration into SAP. There are several of them, but the market leader (they have approximately 80% of the market) is Paymetric. The company has been in that space for over 10 years and has a few very sharp individuals at the helm. They offer 2 main products:

1. XiPay – Payment Card Processing
2. XiSecure – New Product that handles Payment Card Tokens (discussed in another article)

History of the XiPay Solution

XiPay has come a long way. I first saw it in 2002 and then it was just a collection of SAP programs designed to address the gaps within SAP. So they were attempting to address the second problem with the SAP functionality, namely, the functionality gaps. You still had to develop your own interface with the bank.

I next saw it in 2007 and it now offered a fairly comprehensive solution. It now also comprised of a separate server that took care of the interfaces with a slew of different payment processors and banks. To activate an interface with your bank or payment card processor,  you needed to add that banks software “cartridge” and make a few configuration settings.   A pretty elegant design.  That solved the biggest problem described in the first paragraph.

In the latter part of 2007, the payment card industry introduces a set of new data security standards (discussed in a previous article) that had to be complied with if you wanted to process payment with credit cards. This PCI Compliance changed the face of the payment card industry much the same as SOX changed the face of businesses several years ago.

What does it give you?

One big plus of the on demand solution, I think, is that it gets rid of the XiPay server that you need to maintain at your site  (in practice, this was at least 2 servers, 1 for your development and QA environment and 1 for your production environment). It was fairly specialized and I found that despite spending time with the Paymetric technical resource, our Basis person (who was good), still had to schedule time with Paymetric anytime an installation or patch had to be applied.  This created several delays in our implementation.

With the introduction of the on demand solution, instead of having to support about 1000 customers server installations, paymetric now only has to support one. And all the clients hook into this server.

With the XiPay On Demand solution, that technical maintenance aspect goes away, allowing you to focus on your core business again.

If you also implement a payment card token system, such as XiSecure (discussed in an upcoming article), the PCI Compliance become even less of an issue.

Conclusion

The paymetric XiPay solution simplifies your payment card processing in your SAP implementation and the on demand aspect provide some real advantages on an on-going basis.

Feel free to add Comments and Questions.

What is the biggest problem with Credit Card Data?

A tongue in cheek reply would be: “The Credit Card Data dummy!” While it is a tongue in check reply, there is some truth to it.

Having been involved with many implementations, I have seen this over and over. It is always an issue securing and protecting this data and only displaying it to those that need to know. Here are some classic issues I have seen.

Most SAP infrastructures include a Quality Assurance client for testing changes before moving these to the Production environment. And it is very often a copy of Production at some point in time. And what comes over with that copy? All the customers Payment Card data. So you need to do 1 of 2 things:

1. Purge the Credit Card Data (have to write a custom program)
2. Encrypt that data – very often not activated in the QA environment. And quite a process to turn on.

The Result of Encryption

When a credit card is encrypted in the database, it is displayed as ************4141 for example.

The problem is that it needs to be displayed everywhere like that. I have seen instances where someone will run a report and the unencrypted credit card will show up. Or someone enters a transaction from a different direction, or accesses a rarely used screen, and suddenly the unblemished, unencrypted credit card data show up.

And in reality, the Payment Card is still saved in our database. And we are responsible for securing and protecting that data.

What is a Token

What if we could move the Credit Card data from our database and give it to another server (called a Token Server)? The Token server then gives us back a Token that is representative of the Credit Card data. So the actual Credit Card data in our databases, is now replaced by a Token data.

For example: It gives us back ************4141 to store in out database. The only link from the token to the Credit Card data is now held on the Token Server.

Advantages of Tokenization

1. Now we do not have the credit card data in our database. If someone hacked into our database or a user accessed the customer Payment Card data, they could not do anything with the ************4141.
2. Obviously the Token Server needs to be secured and PCI compliant. But this means that we only have one system to secure, instead of potentially many systems.
3. And if we contract with a 3rd party to supply this Token Server, we have now moved the responsibility off site to another company whose core business is to secure such data and remain PCI compliant.
4. This reducing our costs.
5. If the Credit Card data is ever needed, a query goes out to the Token Server which returns the Credit Card Data. This makes PCI compliance much easier as we do not store Credit Card data on site anymore.

Who offers these Tokenization Services for SAP

Probably the best known of the Service Providers is Paymetric, with their XiSecure Service (they use a 25 Character Token).

1. XiSecure – Onsite local Installation
2. XiSecure – SAAS Hosted Offsite Service.

Whilst I have not implemented a Token system yet, it makes sense and would be a useful compliment to a Credit Card Payment System.

Paymetric Implementation masks a Looming Change to the Payment Card Industry

What led to the Payment Card Industry Change?

New Payment Card Industry Data Security Standard (PCI DSS)

What are the PCI Standards?

1. Build and Maintain a Secure Network
   • Requirement 1: Install and Maintain a Firewall to protect cardholder data
   • Requirement 2: Make sure you create and use your own strong passwords (don’t use vendor supplied passwords)
2. Protect Cardholder Data
   • Requirement 3: Protect stored Cardholder data
   • Requirement 4: Encrypt data transmission of cardholder data across public networks
3. Implement a Vulnerability Management Program
   • Requirement 5: Use and regularly update Anti-Virus programs and measures
   • Requirement 6: Develop and maintain secure systems and applications
4. Implement Strong Access Control
   • Requirement 7: Restrict access to cardholder information to strict business need-to know personnel
   • Requirement 8: Each person needs to be assigned a unique ID for computer access
   • Requirement 9: Restrict the physical access for cardholder data
5. Regularly Monitor and Test Networks
   • Requirement 10: Track and monitor all access to network resources and cardholder data
   • Requirement 11: Regularly test security systems and processes
6. Maintain an Information Security Policy
   • Requirement 12: Maintain a security policy that includes both employees and contractors

PCI Compliance & PCI Audit Requirements

1. A PCI data security assessment (on site or self assessment)
2. A Third party network scan (quarterly or annually)

Consequences of Non PCI DSS Compliance

1. Card Companies may impose fines up to $500,000 on the Banks if their merchants are not complying.
2. Merchants could risk losing their ability to process credit cards
3. Business’s whose cardholder data has been compromised, are obliged to notify legal authorities and provide free credit-protection services to those who are affected.
4. Cardholder’s may sue you. This may lead to bad publicity and potential loss of business.

Conclusion

I hope this brief overview of PCI DSS has been informative.

I have spent the past 5 months working with Paymetric’s solution for SAP credit cards and I must say I have been impressed.

I first came across Paymetric in 2002 when supporting Credit Cards from the CRM side and they have come a long way since then. I was impressed with their expertise at that stage but their solution was not as comprehensive as it is today.

They have had a long and comprehensive look at SAP’s standard solution for credit cards and developed their offering to fill the gaps and improve the functionality.

Here are a few examples:

• In standard SAP, the customer needs to decide up front in the sales order to pay by credit card. It is not possible to pay for your open A/R balance later. Paymetric’s Open A/R module allows you to select Open balances after the fact to settle with a credit card.
• In standard SAP, if you have a billing plan of say 3 bills of $5,000 each, SAP will attempt to authorize the whole $15,000 instead of only the amount with in the configured horizon. There is a way of using the Auto A/R module to cover this.

The solution comprises of a group of SAP programs (imported as a series of transports) and a separate server called XiPay (actually server is a misnomer, it is actually a piece of middleware that communicates with the payment processor). There is also an encryption/decryption server which resides on the same box.

The XiPay server is where you get a lot of value, as Paymetric has certified their interfaces with the processors (and they support quite a few). This save a bunch of development and testing time.
Even though the solution is vastly improved, it does not necessarily mean that you do not have to add code to user exits.

For example: It does not support Invoice Cancellations out of the box. You need to add some coding to cover the 2 scenarios: before settlement and after settlement. Actually, most of the coding is related to the XiPay side in this case. Another example is Billing Plans. A bit of code needs to be added to handle these.

Whatever you do, do not underestimate the effort still involved in implementing credit cards as we have discovered. Paymetric definitely does shorten the implementation time dramatically, but do not get the illusion that it is a plug and go.

I have also been very impressed with the caliber of the Paymetric consultants when we have had questions or issues.

In summary, I think it is an excellent solution and well worth the investment. It will shorten your credit card implementation time and really improve your final solution.

This morning I was musing over the fact that I had not heard a large emphasis on change management for a few years now. When I started with SAP (early 90′s), change management was the big buzz word. Every project had a dedicated raaa raaa change management team. Am we were made very conscious of the vital importance of change management for the success of a project. Because let’s face it, we were introducing huge changes to the business. And their acceptance of these changes could make or break a project. And my first 3 years of SAP experience was in South Africa. South Africa has this curious mix of first world and 3rd world. So quite a few of the rollouts I did involved actually teaching users how to use a computer and then how to use SAP.

In fact on my first project in the US, we even had a user take early retirement to avoid having to learn how to use SAP. In another case, the users refused to use MRP and it was eventually switched off.

So what is Change Management? The definition I like is: Overcoming resistance to change. So how do you do that? From my observations and experiences, it involves helping users realize several things:

1. SAP is going to help me do my job better? In my case, I tend to work on the Customer Service and outgoing logistics side, so the users I deal with want to serve the customer better. This is not always from the companies perspective. This is often just a case of, can I answer all the questions the customer puts to me (do I have easy access to the information). Let’s face it, it’s an unpleasant job if your customers scream at you all the time.
2. Is SAP going to make me more productive or is it going to make my job more difficult? In today’s information age, having the right tool for the right job makes all the difference in the world. Example: If you ask me to calculate a whole table of financial and sales figures with MS Word, I can probably do it, but it would be painful and very time consuming because MS Word is not designed for that. However, give me MS Excel and life’s a breeze
3. Is SAP going to save me time which is similar to point 2? So that I can work shorter days and spend more time at home with my family.

Keys to Change Management So how do we get users to embrace and welcome SAP? From my observations the following points are crucial:

• A colleague of mine always says:
  

  A fish always rots from the head

  Support for the project and it’s goals must come from top down. It never ceases to amaze me how a company can spend millions on an implementation and then refuse to pony up the appropriate resources and time to design and test the crucial business processes and make the crucial business decisions. Or the users they pony up end up doing 2 jobs: there normal job and the project.

• Involve the users in some of the decision making and definitely in the testing. SAP is going to directly affect their job. Yes management benefits from the increased availability of crucial business making information, but who puts that information in the system – the users.

• Allocate sufficient time for training. Users do not want to struggle or appear incompetent.

• Let users know what is changing. here are 3 strategies I have seen work well:

• A “Show & Tell” session or “Lunch and Learn”. Invite users to a demonstration of a business process. Great time to verify that you have not missed anything. You would be surprised how often this brings up something you have missed. Tip: Get a user to do the demo.

• A more formal process is a “Conference Room Pilot”. On one of my projects we had 1 scheduled every 6 weeks. It acted as a project milestone to showcase what had been accomplished. It was typically 3-4 days, also involved smaller breakout sessions to gather more specialized feedback and information and an evening social event. And people flew in from all the plants. It worked extremely well.

• Publish a regular newsletter.

• Get Regular feedback from users (maybe anonymous) to elicit rumors, concerns and fears.

The ultimate goal is to prove to the users that the new system is going to provide them huge benefits. Thus reducing their resistance to change. With the increased frequency of smaller companies implementing SAP, this becomes more and more difficult to accomplish. The reason is that these companies have excellent people but are typically lean to start with. One person often wears many hats. One of the big “criticisms” of SAP implementations in the early days was that they absorbed key personnel for extended periods of time (sometimes years). Be aware of this and plan for this and plan backfills if necessary. In a bigger implementation I did in the UK, the company identified 10 people for the project and backfilled their positions 100%. Unusual, but highly effective. In summary: SAP Change Management is answering a simple question.

How do I persuade users that SAP is going to provide them benefits over their existing system thus reducing their resistance to the change.

For some time now, I have been looking for a flexible, user friendly script, that would allow me to create a testimonial gathering page. While I could get a script developed, it makes absolutely no sense if I can buy a ready made script for under $50. And it includes all the bells and whistles. Today, I was found this script that looked like it had everything I needed. I was quite excited, downloaded a trial version, and installed it on my server. Much to my dismay, I discovered that to customize the forms, you need to open a .php file and manually change the settings in the file.

This reminded me of working with SAP. Sometimes the incredibly rich functionality is marred by crummy usability. When you come to use it, you can only wonder what the developer was thinking. The screens and user interface seem to added as an afterthought.

When I worked for SAP (in the CRM area), I worked at a client who was a Beta customer for SAP Leasing and Asset Management (SAP-LAM). As a Beta client, SAP listened to their requirements pretty closely, to drive the direction of the solution. We had a lot of interaction with the leasing developers in Germany. In fact, they flew in for a week at a time to discuss requirements and possible solutions, and showcase their development every few months.

Now, leasing is not a trivial solution. I can honestly say, that SAP-LAM is the most complex SAP industry solution I have worked with (and I have worked with quite a few). I was always amazed at the attitude of the developers towards usability. When challenged (because it was difficult to use), their comment was always: “We will worry about usability later”. I always thought this was a crazy approach.

This implementation was scrapped several years later. I do not know for sure, but I think that poor usability was a factor in this decision. Particularly, when you start to compare the SAP screens, to the slick and appealing web user interfaces of today.

I worked at another client where usability was the prime reason that they chose not to use SAP-CRM. I spent about 2 months creating a custom user interface using GUIXT to try to convince them otherwise. The comment was made that the users “hated” the screens.

Both of these examples were several years back, so anything could have changed since then.

Here are some reasons to always consider usability in your custom solutions.

1. The whole initial MySAP initiative is an example where SAP thought of usability afterwards. This resulted in essentially placing another layer on top of SAP to make it more usable. Adding another layer can only impact performance negatively.
2. If users are exposed to the “raw” solution at this early stage, they develop and inherent dislike for it, no matter how good it looks later. And it takes a lot to change that perception.
3. It causes “bad press“.
4. If you define the workflow (as the user would use the screens to do their work), the code becomes cleaner and more modular.
5. It is so easy to mock up “dumb” screens in SAP using the Menu Builder and Screen Painter to give the user a feeling of how it will work. Web and other application usability designers, use the the same approach, when they mock up screens using simple HTML.
6. It is difficult to train users if the usability is lousy.
7. It really slows the users down with a non-intuitive process, thus affecting productivity.

Defining Usability
The following factors are things to consider when looking at usability:

1. Screen design (this includes: field labels and placement; groups of fields and labeling of groups; tabs;…)
2. Workflow – I am not referring to the SAP workflow functionality here. I am referring to how does a user do their work. Example: Input a customer # it in this field, tab to next field, input their street address, … How do they process the data in the screens.
3. Are the screens intuitive? And if not, is there some easy help available? When I press F1 on a field, does it give me a meaningful description?

My recommendation is:

If at all possible
Design and mock up your Screen and Workflow first

I think you will be surprised by the difference it makes.

Feel free to add you own comments and experiences to this article.

Regards
The SAPGuy

PS!
I did not buy this script because of the usability. I want to drive the car, not spend time under the hood !

In the previous article, I gave two examples where outsourcing cost way more than was apparent. In this article I will begin to delve into some strategies and tips you can use to make outsourcing work. Firstly, let’s examine some concepts and questions you need to answer for yourselves before you embark on the outsourcing journey. And it is a journey. I believe that getting clear on what you are trying to accomplish here is a key to outsourcing success.

Question 1.
Why are you thinking about outsourcing?

Some reasons may be:

• To save costs (usually the reason)
• To get some temporary resources. In other words leverage.
• To outsource all SAP work. This is not your core competency, so makes sense to move it out of the company.

Question 2.
What are you thinking about outsourcing?

Some examples are:

• Some customer specific enhancements
• All your development
• All your help desk and support
• Just you BASIS support
• Functional modules such as all the Financials
• All your mailing and printing
• Your distribution of your products
• Fulfilment of rebates
• The hosting of your SAP system (services based environment)

As you can see, the variety is large and the requirements for each area would be vastly different.

Question 3.
How are you planning to manage this?

This is key. This is the reason why most outsourcing fails. Many organizations have the illusion that outsourcing parts of their SAP system or implementation is like outsourcing the stuffing of envelopes. When you consider that the average implementation costs millions and affects every aspect of your core business, this is crazy.

SAP becomes your integrated business execution platform and the very survival of your business depends on it. It is in your best business interest to effectively manage your outsourcing teams. I will discuss this in more detail in a later article.

I want to make another key distinction here. There are actually 3 categories of outsourcing. It is vitally important that you do not confuse them because they differ in the level of involvement required by you.

1. Out Tasking – Where you simply outsource a task. Once the task is complete, the relationship typically ends. Next time you needs some more work done, it will probably be done by somebody else. You manage this.
2. Outsourcing – Longer term relationship where you use the same person or groups of people. You typically manage them.
3. Out Teaming – Similar to Outsourcing. However, in this case you also outsource the management of the team to someone.

Answering these questions will help you get very clear on your needs.

That all for this now. In the next article I will discuss some typical issues and potential problems you need to consider.

Feel free to add comments to this article.

Best regards and keep warm.

– The SAPGuy –

Provocative title. I want to make a significant point. Outsourcing, if handled incorrectly, can produce crap.

Let me give you 2 examples.

Example 1

Business Scenario:
All European orders were shipped out of a separate distribution company in Germany. This company was not on SAP and used an older legacy system. We had to find a way of transmitting the orders from SAP to them and receiving the shipping notifications back, to pick the deliveries.

Solution:
The team wrote a detailed specification, for an interface out of order entry, which transmitted an order to the legacy system and automatically created the delivery. Once the delivery was shipped, the legacy system sent back a confirmation with the quantities, that were then used to pick the delivery.

To try to save costs, project management decided that this was an ideal candidate to outsource offshore. Six weeks later, the first prototype arrived back. It was as if they had not read one page of the specification. When we tried executing the program, nothing happened. It took another 3 months to get a stable version !!

This is something that could have been written on-shore in about six weeks. And the quality of the code would probably have been far superior. On the face of it. it looks like it only took 3 times longer. And that it was probably still cheaper. But if you start taking into account the additional cost of the functional consultants and users time, to try to test this mess, I think you would be shocked. It amazes and puzzles me why projects do not track individual costs this closely. But, on the other hand, I think I understand. I think the numbers would shock and dismay and there would be threats of pulling the plug.

Example 2

Business Scenario:
The company used scanners to process returned products.

Solution:
It was decided to write a custom front-end to process product returns, as they had some unique requirements.

It was outsourced offshore. We eventually got it working after months of going back and forth. However, there was so much flack from this small project, that I believe (although it would be denied), that it later contributed to the head of development losing his job.

After going live, every time we discovered another bug, we cringed. Touch one thing and another thing breaks. Several of our Class A coders had looked at it and the universal comment was: “Rewrite”. But, as is often the case in projects, no time, resources, or money. Band-aid, pray, hope and hold on.

These two examples both illustrate one key thing. While outsourcing can save significant money, if it is not managed correctly, it can cost more than you bargain for. Both in money and more importantly, in quality. Bad quality code means ongoing maintenance and support costs. It feels like a bad penny, it always coming back. And your best developers often don’t want anything to do with it.

Make no mistake, there can be huge benefits to outsourcing. However, it needs to be done right. In Part 3, I will begin discussing some of my observations to help maximise some of these benefits.

Feel free to add you comments to this article.

Regards
The SAPGuy

If there is one key to a successful implementation, it is simply this:

TESTING !!!

Duh. Well that’s obvious. Well if it’s that obvious, why do so many implementations fail to do a decent job of it? It just amazes me, the number of times that I am standing behind a user doing go live support, and something does not work. Often, this is Day 1 of go live. Was this not tested?

What Types of Testing are there?

Through the years, I have compiled the following list of testing types that must be done.

Ignore any of them, at your peril.
This can and will cost you a smooth implementation and a lot of money.
Users will hate the system, politically, it will not be seen as a success and the costs to fix things can literally go on for years.
Just when you thought the cost of implementation was over, it will go on, and on, and on..

You get the idea.

Look carefully at this list. Notice one thing: the types of testing, generally correspond to the phases of a project and they are often done by different groups of people.

• Functional testing
  Does the application work as designed? This can be a standard SAP business process or a customer specific extension of the code. It can be executed by any team member or the users.
• Unit testing
  This is also known as horizontal testing. Does the process work on it’s own? Ignore all integration. Is it doing what it should be doing on it’s own? In Sales and Distribution (SD), this may be from order to billing.
  
• Integration Testing
  This is also known as vertical testing. After unit testing is successful, does the module or process integrate correctly with other modules (example: If it posted to Financials, are the postings correct?)
• User Testing
  This is crucial. The most successful implementations always second some key users to the project (and backfill their positions temporarily). And note that testing for a single week will generally not cut it. It will require longer involvement and possibly ongoing involvement by the user(s). Users always find things that project members miss or never thought us.  Lets face it, they use the system every day.
  

The old tongue in cheek joke is: “Without Users, this system would be perfect”.
But in truth, their involvement and sign off, is crucial to your successful implementation.
Remember, as far as they are concerned, this is just a “dumb tool” to help them do their jobs.
Management may be looking for the statistics and the integration.

The user does not care !!!
All he/she wants to know is: “Will this help me do my job better?”

That’s been my experience. Everybody wants to do a good job. There is nothing worse than having a tool that makes my job difficult.

• Performance Testing
  In the past three years I have been working in Call Centres. So I have become acutely aware of performance. In one of my clients, a key metric was a 20 second order (we had to built a custom front-end to order entry)!

  In other client, we spent a year developing a custom solution to track freebies, put it in production, and then discovered that the “nightly” job run, ran for seven days !!! It took us another 4 months to get the same program to run in 7 minutes !!

  Often performance testing is neglected or poorly done. And if you are running a multinational roll out, you had better get it right.

  A lot depends on your development environment here. Do you have a box with enough “live” data to test on. And how close does this match your production environment?
  

• Regression testing
  In the last few years I have been involved in the medical devices industry with several clients. They have to comply with the FDA and run so called “validated systems”. In the last four or five years, SOX has also been a huge impact to SAP implementations. So I have become painfully aware of the need for both doing and documenting regression testing. It has always been done, but the need to document it has not always been  required.

  What is it? Simply put: If you change anything (a configuration setting, a process, a program), you have to test everything related to that change.

  Integration is one of the massive advantages in SAP. But it can also be curse when you are making changes. Because by changing a small thing, you can effect everything. All implementations learn this, usually the hard way.

Practical example:
An recent client told me this story. A change was made. It was tested in the test environment, integration environment and again in the staging environment. Everything looked great. They promoted it to Production.

Production crashed !!!
The system was done, worldwide, for 3 days !!!

Turns out, that it was an Oracle bug, which only showed up in a multiple application server environment. None of the testing nor development systems had multiple application servers – They never do. So you just never know.

• Migration testing
  This is a type of regression testing and refers particularly to an upgrade. Take your time here. Things break in upgrades. Particularly if you have many custom programs. Or you use GUIXT to make screen changes (by default it identifies screen fields by their description. So if the SAP description changes in an upgrade, it will not work. Easy to fix).

Who should do the Testing?

This is key. Not all of us are good testers, period. To be a good tester, you need to be detail orientated. People have said that I am a good tester. But, to be honest, I am an OK tester. I know what needs to be tested, but I can only handle a certain amount of detail before it drives me nuts. Find people who love “breaking things”.

Make sure you identify uses with these characteristics too. Better yet, if they are in responsible positions (head CSR,..). They will have to answer to their fellow colleagues, why the system that they tested, does not work properly or makes their jobs difficult. In my last implementation, there were five people (rare) on my team who were excellent testers. I knew that if I wanted some of my work tested, to give it to them. They always found stuff that I had missed.

Automating Testing

I am covering this not because it is typically done, but because it is typically not done. Clients do not want to spend the money. But, long term, this could save you a fortune. Now it is not easy and requires an initial investment to set it up. And a smaller ongoing investment to maintain. But the long term value is enormous. Think about this: Typically, an upgrade can take 3 months if you have an average amount of custom code (most of my implementation have a lot of custom code). And most of that time is spent testing. And it requires a team of bodies. What if you knew exactly what had to be tested and could run a series of automated test scripts, to tell you in a few hours, what had broken? How much time and money would this save?

Remember, most of us are not good testers. And if it is not your strength, you often miss stuff, and TAKE LONG. So by using good testers to set up the tests initially.

If you found this article informative, feel free to add comments to my blog. And pass it on.

Regards
The SAPGuy