A Simple Way to Validate SAP B1 for ISO Audits

If you are in a regulated industry or are ISO certified, you may run into the issue of software validation of SAP Business One. While Scientific Device Laboratory has an ISO 13485 certification, I have no software that's part of a product. Still, as mentioned in the ISO guidelines, ISO-certified agencies will require you to validate all your 3-rd Party support software. In this newsletter, I want to talk about How to do that for SAP Business One.?

Validation is written evidence that a software application works as expected. In a fundamental sense, you do that by getting expected results from a series of actions to the application. For example, software validation for Excel would give evidence that Excel can add, subtract, multiply, and divide numbers. My Excel validation also provides evidence that it can format and sort numbers and words.?

Now that might sound crazy to anyone who hasn't done this before. Excel is a product used by millions of people. However, auditors will want to see evidence that all MSOffice products work as expected. Excel and Word are what I'm referring to as 3rd-Party Software Applications. You could argue that their use by many people constitutes evidence that the application works. That applies to SAP Business One, and a lesser extent, other SAP ERP offerings. However, that doesn't fly in an ISO Audit in my experience.?

I'm going to put a disclaimer here. I'm going to tell you that this is based on my experience over four years of ISO audits with a single certifying entity and one assigned auditor. Your experience may vary and if you have regulatory people or consultants, listen to them more than me. I'm just going to give you a framework for what you want to do.?

I'm only going to talk about the 3rd Party applications. If you are adding software of any kind to a physical product, you've got a lot more work ahead of you than what I'm going to suggest here.?

Determine Risk

If you think about all the software you use in your business, you'll be surprised how much there is. Both online, mobile, and desktop applications can number in the hundreds, even for small businesses. You, therefore, start this process with an inventory of all your applications.

Since our topic is SAP Business One, this isn't as easy as it seems. When I say Applications, I'm also separating modules of SAP Business One. Sales orders are different from production orders. You'll need to list all that out.?

Once you do, you find ones that contain a risk as far as ISO is concerned. There are different ways of determining risk. I made a form to figure it out for each item based on scope.?

1. A product that contains software
2. Software used for the direct production of a product
3. Used for functions within the quality system leading to quality decisions
4. Affects customer satisfaction with products.?
5. None of the above.?

I'll rank the software and modules by this scope. For example, the financial module will all be 5. Sales Orders affect customer satisfaction, so those would be 4. We have SQL reports that we use to make quality decisions, so SQL Manager is 3. Unless you have direct controllers measuring quality levels with SAP B1, you probably won't see a #2. I consider the design of product #2, so our CAD packages are #2.?

#1 is those items that you are in for a very extended validation. Such involved validations are not related to SAP B1, thus out of the scope of this column.?

Requirements and Risk

I also define software requirements for each application. Requirements are a list of what I want the application or module to do. As an example, let's look at a sales order. I'd list the following:??

• Connect to a customer account to pull customer information
• Add items to the order
• the order correctly adjusted inventory
• The order saves and can be retrieved later.?
• The order gives the total price for the items ordered
• the order prints.?

If an item is in scope 1-4 when I Initially evaluate it, I'll do a validation and skip it if it is #5.?

Changes to Software

Changes to software may be version changes of a published software or a change to a customization.

After I validate once, I evaluate if a need to revalidate on any change. If it affects at least one requirement, then I decide if the validation made a significant change. For example, adding bold to the total on a sales order affects several of those requirements. Such a cosmetic change, however, is not significant. On the other hand, if I add local and foreign currencies to the sales order, I'd have to revalidate since that is a considerable effect.?

In all other cases, when I change software, I skip the validation. The risk is too low to be of significance or relevance to the quality system.

In this process, make sure you look at customizations and add-ons for SAP B1. Many of those will need validations too.?

I don't validate reports from Crystal Reports or SQL. Instead, I validate Crystal reports and SQL and consider the reports created the same as creating a Spreadsheet in Excel - just data for that application. As long as the function work in the application, the report will be correct.??

Writing Scripts

After going through this process, I'll have a list of validations to do. For each validation, I make up a script to prove each requirement gives expected results.?

A script has a header that contains information on the version and all the approvals necessary as I go through the Validation process. Below that, there is a table that includes the following columns:?

• Step Number: I label the steps in the process for reference in any other documents.?
• Requirement number: This is a reference to the Software requirements I discussed earlier. The software requirements rarely change, but the change to the software is more frequent. Requirement numbers keep the requirements standard over multiple changes.?
• Functions to be validated: This is an action whoever performs the validation will do.
• Expected outcome: This is what is supposed to happen after the operator does the action.?
• Actual outcome: this is what happens.?
• Is actual outcome the expected outcome: this is a yes or no question.

Here's the beginning of one for a business partner:?

I have a template to make these up, which includes more columns we'll talk about later.?

Once a script is made, the quality department reviews and signs off on the script.?

Do the Validation and Collect Documentation.

Once created, I'll do the validation. I'll perform the step and then do the most crucial part of the entire validation: collect documentation. IF you don't show evidence you did it, it doesn't exist. You need a lot of screenshots to prove your point. I print these out and mark the printed copy with the step number for reference.?

You test and collect documentation of the test results for every step. There are some scripts where you will repeat steps. For example, I have requirements that if I use Production order routing, I iterate over moving and inserting items around the routing. I'll make a separate document giving all the possible cases that the script will run through. For each case, I'll provide evidence that the action performed as expected for all the steps. Collecting the documentation can run to hundreds of pages for a single validation.?

It is the most tedious part of the validation, but getting documents for everything is the most important.?

Mismatch or Discrepancies

A good validation will have every outcome match every expected result. But once in a while, you will get a mismatch. I've never had it happen in SAP, but I did get a variation spike in a 24-hour long validation for temperature sensor software once. While it was supposed to maintain a range of temperatures, it spiked down for fifteen minutes. The validation was in early January. Unfortunately, someone opened an emergency exit door near the validation testing. I happened to be there at the time and documented the change in conditions. I then re-evaluate, given this information, if the risk is acceptable. Fortunately, the product was discontinued shortly after this, and I never had to do the validation again.?

The Validation is Complete

After getting all the paperwork together, I have a quality supervisor review and approve all the work I just did, ensuring all my documentation is there. Finally, the quality team files the validation.?

Agin the validation might happen again if changes to the software warrant it. On SAP Version changes, I usually re-validate as updates affect everything. For patch levels, I evaluate what the patches affect.

ISO and regulatory agencies are often nitpicky about having all third-party software validated. I've seen people argue that millions use Microsoft Word or Excel, which should be enough validation, but the auditors still want the paperwork done. These third-party validations like SAP Business One require paperwork and time but reduce the issues for ISO auditors to find.?

Steven Lipton is Chief Information Officer of Scientific Device Laboratory, a Medical Device Manufacturer and OEM of Printed Microscope slides and other Laboratory supplies. Steve is also the author of the SAP Business One courses in the LinkedIn Learning Library, including SAP Business One Essential Training and SAP Business One Reporting and Customization.

BizONEness is Steven's newsletter giving advice on SAP Business One topics not covered in his courses. Subscribe above, or go to BizONEness.com for back issues and more information.