Xpandion creates “behavior-based profiling” for business applications. Sounds impressive, huh? However, do you know what it means, exactly?
I, for one, feel confident when implementing new software on a client’s server or on our secured cloud; nonetheless I can’t necessarily say the same about the customer... Sometimes I feel that customers are a bit nervous when I’m around, especially when I ask questions about their SAP authorizations or SAP licensing contracts.
It’s not that they’re scared of me – after all I’m quite a nice guy – what customers fear is that their ERP system/s will slow down, or even stop working following the implementation of new software.
When I think about the severe consequences a business could experience if its ERP system malfunctioned in any way (and for any reason), I can’t say I blame those fearful customers. Imagine if you were in charge of the ERP system in your company and someone – inquiring about security or structure of authorizations – was in the process of implementing a newly purchased product. You too would be extremely cautious (and nervous) of any changes made to the system, no matter how amazing the product turned out to be. After all if an error causes the ERP system to stop, resulting for example in leaving trucks waiting for goods, your job would unfortunately be in danger. Now who would want to take responsibility for that?!
It seems to me as though clients always have the most persuasive argument for their fear. They logically explain to me that they need to consider what there is to gain and lose by implementing a new product. In their words: We need to carefully weigh the benefits of the product against the risk of unsuccessful changes resulting from the installation of the software. Again, if the person telling me this is also the person responsible for ERP, I can totally understand (and even agree) with this notion. This is why at Xpandion we are all in favor of the rule if it ain’t broke, don’t fix it. In other words, do not make changes to a client’s fully functional software, unless there is absolutely no other way.
Consider SAP for example: If you are implementing a product externally to SAP, there is no reason to think about how to overcome system changes as a result of the new software, since external installation means that no changes are made to SAP to begin with. Therefore, there would be nothing to fix. You get my point… I’ll move on now…
From day one, we have ensured that our software obeys this rule and does not require adding codes to SAP (in other words, there is no need for an ABAP Change Request). We also use known methods and designs so that end-users remain confident and stay in full control working with SAP, just as they did before.
Take my word, if you are implementing a product installed externally to SAP, there is no risk hovering over the SAP system and surely there is no reason for you to worry about your job… Furthermore, the implementation process of such external products is much simpler and faster; there is no need for SAP expertise, and ROI is exceptionally fast. You will end up saving time and money for your organization, alongside receiving compliments for a successful integration and implementation process. Can’t get much better than that!