Why Building In SAP Doesn’t Always Make Sense
By Clinton Jones on July 16, 2014
There is a school of thought that believes the idea of building workflows on systems outside of SAP is all about dodging SAP licenses–but in reality, this is not the case at all.
The argument against building workflows within SAP falls into a number of broad categories: users, data, organization and development.
Let’s use the example of a purchase requisition. The decision to build this within or outside of SAP often comes down to who participates in the process.
I often use the argument that the person who sits at reception, or a factory worker, has processes that are bound by consumables. Whether it is stationery or cleaning materials, both of these users might place an order once a week and would log on to SAP occasionally.
What if, worse still, the people raising the requisitions, are not even my employees–they are contractors or outsourced resources with whom I don’t have a fully trusted relationship in terms of systems?
If an order is 10 items or more it would be preferable to enter that data into an offline template, such as an Excel spreadsheet. This is especially true if the brief is to consolidate orders rather than raise one or two line orders in large numbers. Often the cleaners route their requests through reception anyway–and if they are using paper to do this, it is wasteful, inefficient and susceptible to transcription errors if paper is used anywhere in this process.
Straightaway you can see with this scenario you have a workflow request happening right there!
Nothing worth having, is ever really free
You could build something within SAP, without a doubt. However even the SAP business inbox requires some training. For an infrequent user, this might be difficult to learn. In addition, there is the requirement that users know and understand how the requisition form in SAP needs to be completed in order for their requests to be routed and attended to. Also, there aren’t many workflow options available that tightly integrate SAP with Microsoft Excel. The only way you could do this within SAP is through costly custom development for every process you want to automate with a workflow process.
The complexity of projects grows pretty quickly, and I haven’t even begun to dive into the requirements gathering or creation of the actual business process procedure.
While it’s often argued that you get Workflow in SAP for free because it comes with Netweaver, unfortunately it comes with a usability and development price, similar to Legacy System Migration Workbench (LSMW), and really begs the question: What are you prepared to spend on expensive IT resources developing in that environment as opposed to other areas of the business?
When we examine the actual development aspects of SAP workflows, like all software development, building SAP workflows has varying costs dependent upon the requirements and complexity of the process. Generally, we find that developing an automated solution with workflow in SAP around Excel or a simply a web form takes almost twice as long with just SAP development products as opposed to using Winshuttle products.
If you are lucky enough to have in-house SAP workflow resources or a friendly ABAP developer who has some SAP workflow skills, then you’re simply burning employee hours to develop any given solution. However, many organizations don’t, so they contract in or buy Workflow resources as needed.
One of the advantages with developing workflows around Winshuttle technology for SAP is the fact that Winshuttle Foundation provides the opportunity to create forms and workflows around business processes without requiring you to have developer skills. You’re also not bound by the same kinds of release cycles that SAP systems typically have, because you’re not changing any of the core logic of the SAP business applications. This removes the pain of waiting for regression testing, transports, patches and releases that are associated with periodic SAP maintenance. Testing and release management is still required but this is all done in the context of Winshuttle objects.
Winshuttle Foundation includes Composer which is a browser-based product that allows you to build SharePoint forms and workflow solutions that are tightly coupled with SAP, enabling accelerated ERP business process innovation. Composer provides a flexible authoring environment for building applications that connect structured transactional data stored within SAP, CRM and other enterprise systems with the unstructured information and processes that underlie all business processes. This direct interaction enables companies to reduce operational costs and increase business process agility via automation and increased data accuracy.
When evaluating a third-party workflow application outside of SAP, consider both the user base, the nature of the data, where the data comes from and the development lifecycle.
About the author
Clinton Jones is a Director for Finance Solutions Management at Winshuttle where he has worked since 2009. He is internationally experienced having worked on finance technologies and business process with a particular focus on integrated business solutions in Europe, the Middle East, Africa and North America. Clinton serves as a technical consultant on technology and quality management as it relates to data and process management and governance for finance organizations globally. Prior to Winshuttle he served as a Technical Quality Manager at SAP and with Microsoft in their Global Foundation Services group.
Questions or comments about this article?
Tweet @uploadsap to continue the conversation!