How to build a business case

/0 Comments/in , , , , , /by

For any business investment you must to is to build a business case so you can show a positive ROI. Otherwise, money can spend on something else that has better output.

The same applies if you want to get a better SAP PI/PO testing up and running. And all of my customers of Integration Regression Tool (IRT) must go through this process. Therefore I thought about helping them out, so you don’t have to start from scratch.

I have created an IRT-ROI-business-case 2019.

There are obviously a lot of assumptions that I have made in it. The assumptions are for a medium SAP PI/PO customer based on my experiences. I have tried to explain them in the video that I have made.

In this case, normal usage of testing would cost around 80.000 EUR a year.
If you go for IRT the first year, it will only cost around 40.000 EUR. The second year would be even better because you have made all the initial investment in the testing.
I was trying to see whether you really should be testing. This part had some nasty consequences like have system or factory down for 2 hours or losing a relationship with a customer. Here the price was 85.000 EUR. It had big fluctuations if you depending on how if your system was down every year or every second year.


Do let me know in the comments if there are ways this can be improved.

Highlights from the Figaf Blog 2018

/0 Comments/in , , , , , , , , , /by

So, here, at the beginning of 2019, I think it will be appropriate to take a look back on what happened on the blog on Figaf.com during 2018.

Last year, we published 35 posts on the blog. Some blogs post were about new releases on some of Figafs´s tools, some were about new insights or how I did see the future and some were about how you can use SAP PI/PO to optimize your workflow. To be honest, I had great fun making all the videos, slideshows and blog posts.  Still, after working with SAP in more than 15 years, I find it very interesting to develop new functions on the different tools, Figaf offers, so that users, in the end, will have a better experience working with  SAP PI/PO.

So, in this blog post, I will take a trip down memory lane and show you the three blog post from 2018, that I appreciate most. Not necessarily, because it was exactly these blogs which had most readers or got most shares or likes on the social media, but because they are still worth reading today in the very early stage of 2019.

Why our testing is different than most test systems for SAP PI

This first post, “Why our testing is different than most test systems for SAP PI“, was published March 24, 2018. This blog is still very interesting, because of two reasons. Firstly, testing is, and will always be, a very important part of working with SAP PI. Secondly, the blog follows up on a podcast with Mark Oshifeso, who is a customer of Figaf IRT.

It is always very interesting for me when customers take time to explain, which challenges they see when they are working with SAP PI. And maybe it will also be valuable for you to read.

SAP PI/PO support, why not learn from the errors

The second post, “SAP PI/PO support, why not learn from the errors“, was published on September 28, 2018. I think it is still worth a read because it is very important to learn from errors and bad created scenarios when you work with SAP/PO.

As you can read in the blog, there are two kinds  of errors in an SAP PI/PO context:

  1. Errors that repeat and solvable by actions like restart the message, refresh of the cache or send mail to the business user in charge.
  2. Errors that occur because a coding error that will be fixed and never occur again (hopefully.

In the blog, you will find a video, where I talked about how you can optimize your SAP PI/PO Support.

Optimize your SAP PI/CPI development

The last blog post I would like you to take a look at is called “Optimize your SAP PI/CPI development“, and was published November 21, 2018. SAP is always in progress, and it is important to set aside time to develop so that your scenarios and solutions always are up to date. In other words, I think it will be valuable for you to take a look at the blog.

In the blog post I talk about a process built on the following steps:

  • Scoping
  • Development
  • Testing
  • Document
  • Transport
  • Validation
  • Go live
  • Support

In the blog, I also talk about a webinar, I held, about how the Figaf tool allows you to optimize and automize the different steps in the process, so you don´t have to have all the manual paper tasks to fill in. You will get much greater visibility into what is developed of your SAP PI/CPI landscape.

I hope you liked the content, I have chosen for this blog post. If so, you might also like to see Highlights from the integration podcast 2018.

If you have questions to the three blogs or other topics regarding Figaf.com, do not hesitate to contact me.

New whitepaper: How to create your SAP integration in 2019

/0 Comments/in , , , /by

So, November 14. 2018, I wrote a blog post, The future of SAP Integration PI, CPI and how to prepare your self, about a webinar, where I talked about the key takeaways from SAP Teched and how to implement things based on. There is a lot of interest in the topic because it is new ground for a lot of customers and consultants. You will need to think about how you are using SAP XI/PI/PO and how you migrate/upgrade. The big new thing that you have probably not been able to avoid is how to use SAP Cloud Integration (CPI/HCI), and now all the extra services.

Now, I am happy to announce that I created a whitepaper about my thinking about SAP Integration in 2019:


You can download it from the Slideshare page.

And why is this stuff important? It is so, because already today you are working with integration, and you´ll probably have to work with a lot of new integration projects in 2019.

As always in something like this, there are functions that changes and you need to make it work in a different way. It is also difficult to capture all requirements for all scenarios so as always it depends on your strategy what to do.

In other words, if you have to be ready for all the new challenges, you have to understand where you are going, the current state of the SAP PI roadmap and how to make integration in a faster way. Once again, I would like you to pay attention to Figaf´s Integration Regression Tool, which supports the full lifecycle of integration. It is a requirement for how you are going to deal with integration.

If you like this, please share or leave a comment.

Why have a full SAP PI/PO regression test case is needed

/0 Comments/in , , /by

Do you have a full set of regression test cases of your SAP PI/PO system and can run them when needed to ensure that nothing is broken.

This week I was talking with a potential customer about our testing tool and the newest feature where they did not need to install anything on the PI system. They did, unfortunately, have a too old version of one of the components to allow us to read the log messages. It was added with OSS 2437778.

It is the standard way out to add new features to patches or service packs to give customers there the features which are required. Most of all the time you want to be able to leverage the new functions in some scenarios to solve a business need.

With the way SAP is delivering the Java code is it cumulative patches. This mean that patch 3 contains updates from patch 2 plus some more changes. So you cannot just get the fix you want as you can with ABAP.

They are also linked with dependencies so if you upgrade one, some part will stop function because it is missing a dependent library. So most of the time you have to update quite a bit of component and you have no idea about how this will affect everything else. You can read the release notes, but it is difficult or close to impossible to predict how this will impact your system.

And to make matters even worse, you probably need to upgrade all components to the latest to ensure all dependencies are met.  

In a normal company it will take a long time to validate these things, so if you’re just adding a simple feature it is really a no go to do this. The business case is difficult to explain, we want this feature to do X, but it will cost a lot of testing. So you have to wait for the business to ask for a new feature and then that project would have to pay for the upgrade/patch.

That’s the reason why I want to have a full set of regression test cases that you can just run whenever there is any patch or an upgrade that you have to ensure that everything works as expected without involving people in the testing of the new features.

The price for an upgrade is a partial basis to get them to upgrade the system and then a part to test the component. The biggest cost is the tests that you need to perform to ensure that everything works as expected. It makes, therefore, sense that to be able to automate that part if it is possible.

With most test tools that take a long time to set up these the test cases and that’s why we’ve created a tool to enable you to set up these test cases fast.  We had a customer Anadarko Petroleum Corporation that could set up 300 test cases in just 3 weeks.

Since then we have optimized the process a lot making it a lot faster to set up test cases. So I would assume you will be able to set up test cases a lot faster than now.

The cost of running the test for the full system is close to zero, so you can run them daily to get information about how the system performs or if anything is broken.

So you can apply the latest support packs if you want to have an updated system with the latest features and fixes.

You can download Figaf IRT tool and use the tool for free upto 10 ICO’s to test on your own SAP PI/PO system. You can request a trial license to get more tests done. If you already have the patch mentioned then you don’t need to install anything on your system and in many cases use your own use for the testing.

 

Migrating Seeburger to SAP B2B Add-on the fast way

/0 Comments/in , , , /by

We have lately seen a large interest in the Seeburger to B2B Migration because SAP PI/PO customers are seeing as a way to bring down cost and optimize. There is a number of factors that allow users to achieve this

  • The new solution from SAP has a lot of advantages making it a lot more flexible and supports the newest schemas. It includes all EDIFACT, X12, Tradacom and EANCOM messages that you want to be using, so you don’t need to pay for each message.
  • It is also simpler to transport since they don’t require the use of the BIC to make the one to one mappings
  • It contains all the same adapters with some new features
  • The price of the solution is also included in your standard SAP PI price so you don’t need extra licenses to make sure you can communicate with EDI for your partners. So you can save money on the maintenance of the Seeburger solution.
  • You have the option to use the Trading Partner Management solution making it a lot easier to maintain many partners and the information from them.

When facing the migration there are some challenges that you must figure out how to solve.

  1. Schemas are different so everything needs to be remapped
  2. Test nothing happens with the output messages.
  3. Budget and planing

1) Schema changes update from Seeburger

One of the issues is the schema structure between the Seeburger and the SAP PI B2B Add-on is different on some different levels. The root element is different but there is also some different naming of groups and fields. In the Swing tool you have the option to remap some fields, but then you need to take manually account of all the fields in all mappings. And if it is not done consistently then you can end up with problems.

I always want to optimize as much manual labor as possible as that is what we are doing with our Seebuger Migration Tool. Simply select the message mapping and the new target XSD and it will convert it for you.

We currently have the free introduction package that contains 10 mappings for free. It is normally 100 USD pr mapping. So it is a really good way of getting started with the migration. That way you can prepare your self for the migration project and understand the complexity and what you otherwise need to move.

In the video below you can see how to get started, requesting licenses that you get to select 10 off for free. Then run the migration. Running the migration for a message mapping takes a few seconds.

Get the free migration tool

 

2) Testing the migration

For any migration, it makes sense to test that nothing vital has changed. It is really crucial for EDI because the importance for the business, you cannot afford to be down for a period of time.

Even if the mappings are validated there is still a lot of components that you need to ensure is not messing up the flow. We recommend using the Figaf IRT SAP PI/PO test tool. You can use it for free for up to 10 Interfaces, so you can use it to validate the migration tool work. The Figaf Testing tool is build to make it really easy to fetch test messages from your production system, and then be able to use them on your development system for testing with. If there is any difference you know there could be something wrong. IRT has support comparing XML, EDIFACT, X12 and other formats.

If you purchase the migration tool for your full conversion we can find a good offer on the test tool.

 

3) Budget and planning

It is pretty difficult to get any budget for a migration project. In most cases, you will halt development for a period of time to perform the migration. It is more fun to spend the money o new development that helps the business. The biggest reasons for a Seeburger to B2B add-on from a financial perspective is that you can avoid the maintenance of the Seeburger application and use the license you already have. The support and maintenance of the new system may also be faster but it will not likely be something that will make it selling criteria.

I have created some blog post that covers more details on how to perform migrations in and make it easiest. They are focused on general migration but it will be the same concepts that are required for the other migration.