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

This is part 1 of a 5 part series.

According to Wikipedia (the largest encyclopedia in the world), outsourcing is the practice of hiring an external organization to perform some business functions in a country other than the one where the product or service will be sold or consumed.

In the last 5 years, outsourcing has been a source of controversy in the USA as thousands of jobs have migrated offshore. Employees have been alarmed and felt their jobs threatened, whilst employers have had no choice if they still wanted to compete in the world marketplace. And this trend is accelerating and is inevitable. The world as we know it has changed, there is no going back.

Buckminster (“Bucky”) Fuller coined the term “spaceship earth” more than 40 years ago to indicate the fact that we are all interdependent of each other. No country can exist as an island. With the explosion of the Internet, telecommunications and affordable travel, that truth has become increasingly obvious. Practically, this has evaporated the barriers to optimizing a business - by going where the resources are cheapest.

Here is a Statistic that shocked me:

Two out of every five human being on the earth today is either Chinese or Indian.
Or stated another way: 40% of the world population is either Chinese or Indian.

With the average monthly salaries of Indians being between $100 – $200 and China being a bit less, it is no surprise that local labour cannot compete.

Being in the SAP industry, I first started to see some outsourcing in the year 2000. There were a few companies that began outsourcing some of their ABAP development work offshore. In most cases, it was a spectacular failure. Although the concept is sound, the actual business processes, best practices and infrastructure to support this offshore development was lacking – simply put: nobody really had any experience doing it.

Today, in 2007, there is rarely a project that does not outsource to some degree. Many time it is dictated by the CFO as a way of saving costs. Many times it does not because the code has to be re-written because it is so bad or is not maintainable.  In my last project a returns order entry screen was written to allow scanning of returns. It was sent offshore. Whenever we found another bug I cringed because I was afraid of what else we might find. Touch one thing and something else would not work. If anybody had ever bothered to compute the cost of this piece of code I think they would have been floored.

Why outsource? Apart from the obvious reason of cost savings, some companies are doing it for another reason. After carefully surveying their core business, they have decided that they are not in the business of IT, they are in the business of selling water or contact lenses. Although the IT component is crucial to the business, why not outsource it to experts in that field? Or so the logic goes.

What can be outsourced? In an SAP implementation, it is generally the development work that gets outsourced. However, I have seen the Basis support and even application support outsourced. In one case, I saw all the accounting outsourced to Hungary.

In this series of articles, we will explore the following topics: The problems with SAP Outsourcing; 10 Golden Rules for outsourcing SAP; 10 Myths about outsourcing; SAP Outsourcing successes and failures.