SAP Usability and Adoption Issues and Answers
It takes more time to create a sales order on SAP than it used to take on my legacy system,” “I need to navigate through multiple screens and tabs and the number of key strokes I need to perform has increased with SAP,” “the look and feel of SAP is not that friendly and sometimes intimidating,”; the list goes on and on and on. This type of feedback from SAP user community is not uncharacteristic and there is certainly some truth to it. SAP is highly integrated software, so it places huge demands on data- particularly the master data which can be quite daunting at times. Also, depending on how they are designed, SAP transactions may involve navigating across multiple screens, even though one may populate just one field on a given screen/tab. But largely the reason for this type of feedback roots back to the drawing board during the design phase of SAP implementations.
SAP projects are often dogged by lofty aims and ambitions during design phase. No doubt, SAP implementations throw out an opportunity to revisit the current business processes and improve upon them from various perspectives, but be careful of what you ask for. ERP software like SAP comes with so many features and functionalities that sometimes, companies tend to over-engineer their business processes based on the rich functionality available in the software. As they try to map their business processes into SAP, companies may embrace what is in SAP and adapt their business processes. They may also choose to put in some additional controls into the processes but sometimes teams may forget the ‘KISS’ rule and go overboard to build more bells and whistles and insist on custom-developing such functionalities.
I would like to see the system create the orders automatically and send for approvals based on various criteria and track the approvals at multiple levels and automatically process them through the next steps of Delivery and Billing and reject them and reprocess them automatically without any manual intervention. Experienced SAP practitioners would have heard it umpteen number of times and such expectations from the companies are not uncommon. While such approach may be helpful, one needs to thoroughly evaluate whether implementation of such controls and additional functionalities is truly required and adds enough value to offset the costs of developing and maintaining them. The costs are not only IT in nature, but running the day-to-day operations with such additional controls and functionalities may require continuous training, more operational manpower or may result in less productivity. Unless there is a strong business case and these costs are justified by something else such as improved compliance, increased customer service quality or some other strategic/financial measure of success, they can become prohibitively expensive. The problem gets exacerbated when a system is designed without considering the skills and knowledge levels of user base. Typically three out of five companies underestimate the impact of such changes and may end up building a huge monster that is likely to bite them later in the game. This realization comes few months or sometimes only a year or two after SAP deployments. This could disseminate the feeling, especially among the executives that SAP is slowing down things and is beginning to adversely impact the business. A simple but objective review of SAP implementation immediately reveals the fact that this situation is more self-inflicted and could have been very well avoided. System integration/implementation partners could also do a better job in advising the companies appropriately during SAP implementation phase.
Take Away: Be extra careful during the design phases; it is mandatory to make sure the operational effectiveness or strategy or both should justify the incremental costs of building and maintaining additional and complex functionalities in SAP. However, for those companies that are already live on SAP and have missed the boat to perform that additional due diligence during SAP design, there are a few options companies can look towards.
Simplify SAP: Simplification is the mantra to improve user adoption. Generally tools and metrics around user feedback, systems operations and other benchmarks at a given SAP installation should provide visibility to whether it is complex or not. If SAP system is considered ‘Complex’, one should first take a look at simplifying the underlying business process. This is critically important as process simplification offers many improvement opportunities on how that process is executed in the system. Subsequently, identify the opportunities to automate the data updates and try reducing the redundancy of data entry. And as one may rightly guess, simplifying the use of any software involves significantly complex back end effort. Hence, it should be made sure again the result is worth the effort. When simplifying a transaction, it is a prudent practice to work towards the targeted measure of the reduction in key strokes and time to perform a given SAP transaction. Needless to mention, performance of the system is not jeopardized during the whole process. Companies embracing this approach have significantly reduced the time users have to spend on the system and diverted the resulting gains to higher value add activities.
However, any such simplifications using SAP classic UI will still have the same look and feel while everyone agrees this is the age of iOS, Facebook, Amazon and Google. SAP classic front end is assuredly antiquated and users always tend to compare any software with these behemoths. SAP has recognized this and came up with new UI tools, SAP Screen Personas and FIORI applications which are certainly worth considering. These are free to use now; implementing them for sure involves some costs, however. These tools are supposedly very powerful, but one should implement them only after completely evaluating all considerations, for example, some or most of the FIORI applications work only with SAP-HANA database. Also very recently SAP has announced the launch of SAP Business Suite 4 SAP HANA that is supposed to simplify the use of SAP and improve the response time by three to seven times. However, a lot needs to be evaluated before companies start switching to this.
SAP is not the Panacea: Another viewpoint IT architects (especially SAP practitioners) should develop is stop seeing SAP as the solution for everything. Companies often end up using SAP to address all their business process needs for reasons that are not small by any means; seamless integration into the overall solution; real time updates; no additional license costs or integration costs, and more. However, for some of the business process needs SAP is simply not the best answer. Optimization of a schedule (production, delivery or maintenance), for example, can be better handled by third party applications that are specifically built to address such needs. Especially depending on the type of industry and the transaction volumes, the answer may not lie in SAP and implementing a third party solution and integrating it with SAP may be the best bet from a long term perspective. This theory can be supported by the fact that the demand for systems integration has grown significantly in the recent past and companies are beginning to evolve with an overall IT architecture on these lines.