In the late 90’s Hershey foods decided they needed to begin preparing themselves for Y2K. While they were getting all their ducks in a row for what would eventually turn out to be one of the most anticlimactic “doomsday” scenarios in history, they also decided to update all their software, replace existing legacy systems, and implement $112 million dollars’ worth of SAP ERP software (Koch, 2002). It seemed like a solid, “catch-all” solution for what many people considered to be the coming apocalypse. Of course, the world didn’t end on January 1, 2000, nor did much of anything else happen aside from a few doomsday cults feeling the sting of embarrassment and plenty of egg on their faces. Hershey, however, was almost certainly looking back on the past couple years and regretting the rushed schedule they gave themselves for trying to cover more ground than was possible in the time allotted. [Read more...]
Mind the Gap: How Small Lapses in Communication can Derail an SAP Implementation and Cost a Company Millions – Part 1: How SAP Can Make or Break a Company
SAP EDI EDPAR Table Walkthrough – How to Cross Reference SAP Customer Number to External Customer Number (Part 1)
When creating IDOCs in SAP to send Invoices to customers via EDI you will likely have to send the customers their internal partner numbers on the EDI ANSI X12 810 Invoice Document. In almost all cases this will not be the same as the SAP partner numbers. So how can we set up a cross reference of SAP and external partner numbers? Well, the answer is simple because SAP has set up a utility to handle this for you. All you need to do is populate the EDPAR table in SAP using the VOE4 transaction. Once this is completed the IDOC_OUTPUT_INVOIC function module will read the EDPAR table when the Invoice document output is processed and populate the LIFNR element of the E1EDKA1 or E1EDPA1 segments of the INVOIC IDOC with the external partner number. Entries in EDPAR can be set up for multiple partners including the Sold-to, Ship-to, and Bill-To numbers so that external customer number cross-references can be passed on the IDOC if needed.
Let’s look at how this process works. Let’s say we have created an invoice document in SAP. In this case, the Sold-to, Ship-to, and Bill-to partners are all SAP customer number 15. If we want to create an INVOIC02 IDOC on which the external customer numbers are populated for all three of these partners we would have to set up three EDPAR entries as displayed on the below screen shot. The Customer field will contain the SAP partner number (Sold-to, Ship-to, Bill-to). The Ext. Function field will contain the Partner Function (SP = Sold-to, SH = Ship-to, BP = Bill-to). The External Partner field will contain the external partner number that the customer is expecting on the EDI file. And the Int. no. field will contain the SAP partner number (Same as the Customer field).
It’s SAP Upgrade Time! Do You Know Where Your Customizations Are? Part 3.
In my final post on this topic, I will discuss some of the techniques that I use to “discover” information about customizations in an SAP system, even in the absence of any documentation. The information available to be discovered may include such details as the object name, object type, user name of the person who made the last modification, date and time of the last modification, usage statistics, where-used, and for code-based objects, even the versions and their code differences.
SAP Mid-Month Go-Live: Got the T-shirt
Conventional wisdom says you don’t go-live with SAP financials in the middle of the month (strictly speaking I should say the middle of the accounting period, but I’ll say month as a generic term for the posting period). I recently went through a mid-month SAP financials and logistics go-live and so far it has been a success.
Initially the project team had the expected you-can’t-do-that reaction when the idea of a mid-month go-live was suggested. We took three main steps to determine whether or not we were crazy or had a viable go-live option:
- We asked SAP. As one of the main participants on the project we got them to do an internal review with some platinum consultants with the objective of telling us why we could not go-live mid-month.
- We asked our project team, both client and consulting resources. Again, the goal was to tell us why we couldn’t do it.
- We Googled like maniacs to find something to support and justify the conventional wisdom. We failed to find anything substantial that would deter us.
Armed with the conviction that there was no reason we couldn’t go-live mid-month we set about defining the details of how we would pull it off.
[Read more...]
SAP Project Management Consulting Clichés – Part 2
Following my previous post I got a couple of responses from folks out on the interweb and decided I’d steal their suggestions and expand on their consulting clichés. After all repetition and overuse are the start point for any cliché and this means I’m doing my part to sustain the cycle – reuse, recycle, renew!
Is Your Project a Hotbed of SAP Consulting Clichés?
I felt compelled to come up with a 2-by-2 matrix to help you decide whether your project is cliché generator or a cliché consumer.
SAP Data Migration – Dealing With Fallout (Part 3)
One of the inevitable aspects of data migration is dealing with fallout from automated data loads. Typically, this process includes identifying the data that will not load, analyzing the error messages to determine the root cause, formatting a readable report that can be used as a tool in the cleanup process, and fixing the root cause of the problem so that it does not happen again.
Why the data will not load correctly.
There is a litany of reasons why some data records will load correctly while others will not. Here is a list of some common root causes:
- Poor quality legacy data.
Legacy systems which are not as tightly integrated as SAP, and are not under master data control allow the end user a bit of freedom when entering data. A zip code may contain too little or too many characters; the email address is not properly formatted; numeric fields have transposed digits; various forms of abbreviations (especially in the city field), a quantity of zero (0) permitted by the legacy system and uploaded into a field where SAP will not accept a quantity of 0 and even simple misspellings all can cause stringent validation checks to trigger an error and prevent the record from loading at all. A more sinister type of error occurs when the data is functionally incorrect, but good enough to pass all of the SAP validity checks. In this case, the data record will technically load into SAP, but will not be functionally correct. Duplicate customers, duplicate vendors, and the data entry error for a quantity of 1000 instead of 100, and the wrong pricing condition applied to a sales order line are examples of this scenario.
- Functional configuration and supporting data effects.
Many times I have watched the load statistics for a data object plummet from near 100% in the cycle two test load to near 0% in the cycle three test load. This is very unnerving to the client because the cycle three test load is getting rather close to the go-live date, and “by the way, shouldn’t the statistics be getting better rather than worse?” Functional configuration changes can wreak havoc on any data load. Flipping the switch on a data field from optional to required; turning on batch management or serialization for materials for the first time; changes in the handling of tax, tax codes, and tax jurisdiction codes; that account determination entry that is missing or not set up correctly; a missing unit of measure or unit or measure conversion factor; the storage location in the upload file which does not exist in SAP – any of these can cause a load to drop mostly or completely onto the floor.While change is inevitable on any project, it is important to control and communicate the change so that the downstream impact can be recognized and understood. Controlled change and communication always works better than total surprise. Perhaps if we all know ahead of time about that data field that is now required, we can impose a requirement on the data extract side to make sure that the data field is populated before it enters the upload file. - Additional data in the upload file.
Inserting a new field in the middle of the upload file data structure might be necessary for the business to close a gap, but if that change is not communicated to the technical team so that appropriate adjustments can be made to the load object’s input structures and processing logic, the new data will surely never load, and may cause misalignment of the data fields which follow it in the upload structure.
SAP Data Migration – The Data Migration Plan (Part 2)
If you are responsible for the success of data migration, you will want to build a detailed plan that will walk you through all of the three phases of data migration: pre-data migration preparation, the data migration itself, and post-data migration cleanup. I like my data migration plan to contain detailed steps that ensure that I don’t forget anything. Each step lists a specific named responsible person along with their area of responsibility and contact information. Unless I am responsible for executing the task myself, I prefer the named person to be a client employee (i.e. the business owner of the process) rather than a project consultant. This is where the responsibility should be, and it requires that the business process owners actually participate in the activity rather than sit on the sidelines and watch.
SAP Project Management Consulting Clichés
There’s an old saying (aren’t they all old?) that instructs you to avoid clichés like the plague. SAP has generated its own set of overworked buzzword terminology and has an eco-viral-collective that churns out more and more each day. I can hardly keep up with the acronyms.
Over the years I’ve accumulated three favorites of my own that I’d like to share. The aim here is not to kill off the clichés, instead it is to suggest ways to head them off before you use one and have clients rolling their eyes at you–Or at least have a quick follow up so that the cliché actually has some value.
The Art of Writing an SAP Functional Specification
Overview
I am currently working on an SAP implementation project that is just starting its realization phase. One of my first tasks, as a member of the technical implementation team, is to review completed functional specification documents for RICEF objects. These documents, written by functional subject matter experts, are supposed to detail business requirements that address gaps, and which need to be incorporated into the system being implemented. The purpose of the review is to make sure that the functional specification documents are complete, accurate, and contain the approval signatures required to move on to the technical design phase.
The Ergonomic User Interface
Every Monday morning I hop on a plane, arrive at my destination city, pick up a rental car, and drive to my client’s site. The car rental company gives me a different make and model car every week. And yet, somehow, I am successfully able to open the car, adjust the seat and mirrors, start the car, shift gears, and drive. I can also operate the radio, air conditioning, heat, windshield wipers, and headlights.
Now, put me behind a keyboard in front of a computer application which I have never seen before. My user experience is all over the map – somewhere in the continuum between most excellent and very poor. Some application user interfaces are extremely intuitive, well-designed and easy to navigate, logically follow the business process flow, and provide real meaningful help when needed. Other application user interfaces are extremely difficult to navigate, are not intuitive, do not follow a logical business process flow, and offer little or no meaningful help. And sometimes in these difficult user interfaces, not only has the location of the steering wheel been moved to a totally unsuspecting location, but its appearance has been changed so that, even when I see it, I do not even recognize it as being the application’s steering wheel.
A well-engineered user interface is no accident. It doesn’t just magically happen. It must be woven into the fabric of the design and the code; and it should never be shoe-horned into the application as an after-thought. It takes a lot of up front planning, designing, testing, functional effort and technical effort to produce a really good application user interface. And yes, designing, building, testing, and implementing a good user interface for your application will extend the delivery time of whatever it is that you are building.
Why is a well-designed and ergonomic user interface so important? You could have built the best application ever developed. But if it is unusable, it will never get very far. Countless hours are lost every day as thousands of frustrated users spend extra time and effort wrestling with poorly designed user interfaces, rather than focusing on their jobs. And when the frustration levels reach a certain trigger point, the users will seek out and find alternative ways to perform their duties.
Here are a few examples of some very interesting user interface experiences that I have personally encountered.
