Data and business process owners: What numbers should we use for Products, Locations, Suppliers, Customers … and so on? A seemingly simple question, but the consequences of your answer are many and without end. Tread carefully!
Implementing SAP S/4HANA illustrates the universal subject, but with nuances that require your attention to stay clear of trouble.
As usual, observing a few experience-based principles can promote good outcomes for Master Data and business processes, now and in future.
This subject rears its ugly head in every SAP implementation project. To define the topic à la Wikipedia: A smart number is any synthetic unique identifier that communicates additional information about the entity identified.
It’s the practice of embedding information in an identifier in an effort to make it “human friendly.” For example, to make the first 3 characters of a part number represent the Department that the part belongs in. Then a user “knows” that a part belonging in Department 123 has a part number that begins with 123. Therefore, the user can confidently say the opposite: All the parts whose part number begins with 123 belong to Department 123. Right? Experience teaches the brutal answer to this question is: Not always. Departments can change over time, as can the parts assigned to them. And that’s the rub.
One of my favorite eloquent arguments against implementing Smart Numbers is Michel Baudin’s: “Why ‘Smart’ part numbers should be replaced with keys and property lists.” By all means, read the eloquent argument. But the simple truth is that we’re just not smart enough to implement smart numbers! It really does come down to the fact that practically all smart number schemes fail over time. Sometimes at inception. Always causing havoc.
It’s fine to be dead-set against smart numbers in principle, and I am. But here’s the practical danger that should put the final nail in this idea’s coffin. SAP S/4HANA exposes internal identifiers such as Product and Business Partner numbers to the outside world. Those identifiers permeate the integrated system, and the identifying number of a master data record cannot be changed. That makes smart numbers dangerous and costly. Just don’t do it.
Numbers for Business Objects
Some business objects in SAP S/4HANA are comprised of multiple technical objects, and each technical object has its own identifying number. An obvious example is Business Partner, which technically includes a plain-old Customer Master if the Business Partner is extended to a Customer role, and/or a plain-old Vendor Master if the Business Partner is extended to a Supplier role.
There isn’t a technical requirement that Business Partner, Customer, and Vendor number are all the same number. To avoid widespread confusion, it’s considered “Best Practice” that all three objects have the same number. The leading business object in SAP S/4HANA is Business Partner. All master data maintenance for this business object is performed using Business Partner number. That includes master data you maintain for any associated plain-old Customer and/or plain-old Vendor master.
But SAP Sales and Distribution (SD) module is unaware of Business Partner; you have to enter the plain-old Customer number when executing SD business processes. And SAP Materials Management (MM) module is unaware of Business Partner; you have to enter the plain-old Vendor number when executing MM business processes. Just imagine the confusion across business processes if Business Partner, Customer, and Vendor number for the same business object are not all the same number.
In SAP Retail, the same holds true — with much wider scope — for Retail Site Master, which mandatorily includes an associated Business Partner. Best Practice for Site Numbers in SAP Retail is that the related objects all have the same 4-character number: Site, Site Business Partner, Site Customer, Site Vendor, and Profit Center Number (for Article Master).
The leading business object in this case is Site Master. A business user is thinking “Site Master” — and therefore thinking Site number — when executing various business processes. But the number to be entered in a given business process — assortment management, for example — could be the Site Customer number. There isn’t a technical requirement that Site number and associated Business Partner are the same number. But it’s sure confusing enterprise-wide if this isn’t the case.
For a given business object, it’s common practice to allocate ranges of numbers for different flavors of the same business object.
For example, Locations that are Distribution Centers might fall into one range of numbers while Retail Stores fall into another range of numbers. Likewise, Products meant for sale might fall into one range of numbers while Products meant for internal consumption fall into another range of numbers (i.e. number range assignment by Material Type).
The standard SAP S/4HANA system supports assignment of such number ranges. It’s common usage. But the scenario should prompt skepticism if its implementation is in fact no more than a subtle form of Smart Numbering.
Historical examples of this include Customer Master records, for which Customer numbers are assigned by Customer Account Group. There are very good business and technical reasons to segregate Customer Master records by Customer Account Group. There are very few good reasons to segregate Customer Master records by number range that aligns with Customer Account Group.
In the beginning, business users will come to infer the “type” of Customer (i.e. its Customer Account Group) from its number. What’s worse, reports and interfaces and business process will be formally and informally created based on this inference. This is entirely predictable because it can be witnessed everywhere. Over time, the idea is exposed as folly when Customer Account Groups change or when Customers are moved from one Customer Account Group to another. In the best case, well-intentioned business meaning becomes unreliable, and in worst case business processes and systems become unreliable or broken.
The point is, identifying numbers — which are immutable — shouldn’t be connected with business meaning (unless the meaning is likewise strictly immutable). Be on the lookout for more subtle attempts as Smart Numbering.
What About Tomorrow?
It’s a bad idea to create master data today based on speculation of what might be needed in future. But we should also take care not to prevent creation of master data in future. Let’s consider Business Partner as a business object to illustrate the case.
Business Partners can be configured to permit extending the Business Partner to a Customer and/or Supplier role. You might configure some Business Partner groupings that are only permitted either Customer or Supplier role, but not both.
Keeping in mind the objective for same number across Business Partner, Customer, and Vendor for the same business object, now is the time to be thinking about not blocking future requirements. That means you should anticipate the possibility of future Customer Account Groups (and number ranges!) for BP Groupings that initially only have the possibility of a Vendor Role. Likewise, you should anticipate the possibility of future Vendor Account Groups (and number ranges!) for BP Groupings that initially only have the possibility of a Supplier Vendor Role.
This is just an example. The point is to consider number ranges and business objects today to avoid conflict in future.
Notes and Asides
- In this document, I use the term SAP Retail as shorthand to mean both SAP S/4HANA Retail for Merchandise Management and SAP S/4HANA for Fashion and Vertical Business.