4 ms·
>changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. It shouldn't be, but it is. This is a common mis
by jasode 7y ago
>changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. It shouldn't be, but it is.
This is a common misunderstanding. Many people miss the underlying philosophy of SAP software. The reason SAP encourages businesses to adopt SAP's way of doing things is that they did research into the optimal way of doing the common business processes that don't differentiate you from your competitors. A common industry lingo to encompass that was Business Process Reengineering. That's why implementations of SAP in the 1990s were done by Big 4 firms to rework the processes of business actions alongside the installation of the software itself. In other words, kill 2 birds with one stone: if we're already spending millions to install ERP software, let's also modernize our business processes into "best practices" because those are already the likely default configuration in SAP.
E.g. there's an optimal way to manage Purchase Orders and SAP encoded that sequence of actions into SAP's data model and GUI data entry flow. You're not going to beat your competitors by insisting that your snowflake way of handling your Purchase Orders is special and "SAP should conform to it". PO's are not your "secret sauce" to dominate the market.
An analogy might be in carpentry where the optimal process is: Measure twice and cut once. -- therefore the standard SAP data entry screen might have 2 text boxes "measurement #1" and "measurement #2"
But another custom carpentry/woodworking shop says SAP is inflexible because they want to customize SAP's system so it's: Measure once and sometimes have to cut twice because of occasional measurement error. -- and SAP's response to that is "you're doing it wrong" -- and SAP's research is often correct -- so don't spend consulting hours to customize SAP into doing the suboptimal thing. Nevertheless, the oddball carpentry shop insists they're "special" so they want the UI text boxes to be customized to be "cut #1" and "cut #2 redo". Well, say hello to expensive consulting billing hours and painful upgrades.
The bottom line is to use SAP for what it's good at: the boring back office enterprise stuff that will not differentiate you from the competition.
> It doesn't care about your USP.
But asking SAP software to "care about your Unique Selling Proposition" is out of scope for the software's intended use. For example, Microsoft and Google use SAP internally even though SAP's ERP capabilities are out-of-scope for Microsoft managing an army of programmers to develop the next Windows operating system or Office suite. Same for SAP not being suitable for Google to run the AdWords system. And yet, Microsoft and Google bought expensive SAP licenses to use what SAP is good for: corporate enterprise financial systems.
- smolder 7y agoThe research that was put into finding optimal processes for those non-differentiating business functions can of course be invalidated at a later time. We all put lead in gasoline because it seemed optimal, then later we kept putting it in gasoline well past the point it was known to be harmful, because everything was designed around it.
- majewsky 7y agoSure. We also found out that Micro-USB as a charging plug for phones does not cover all new uses. But standardizing on Micro-USB was still the correct course of action at the time.
- achow 7y agoNot sure you got the OP's comment. What OP is saying - Perhaps SAP 'optimal processes' made absolutely sense few decades back, but when new time came and world or best practices changed, those optimal processes were no longer optimal, but still one needs to keep using those.. because SAP. From Micro-USB analogy - world has changed, but you still need to keep using Micro-USB for your USB-C phone... because SAP.
- owenmarshall 7y ago> when new time came and world or best practices changed, those optimal processes were no longer optimal, but still one needs to keep using those.. because SAP The underlying assertion here - made without evidence - is that business processes have changed enough to move away from the SAP-defined ones. Have they?
- lostcolony 7y agoThe underlying assertion is there's -no way to tell- any more. Because there's not continual research being done, and there's not even much in the way of anecdotal evidence to inspire research because any large enough company ends up needing SAP (or similar) and has to adopt their workflows as part of it.