| Gürcan Yücel, Software Director |
I am not an expert on the SAP product family. Because of our projects, my path crossed with SAP in many meetings with customers and prospects. As someone who also had the chance to closely follow the early implementation phases of an ERP application, I have made a number of observations over time.
The SAP platform, widely used around the world and in Türkiye, has very high brand awareness. Companies plan huge budgets, build teams, and make investments to own this platform. Backed by management, every SAP project starts out as a "love story".
It is very hard to find an expert consultant for the module being implemented. By the nature of the work, training such a consultant is even harder. They need to know the platform and the module in great detail, match customer needs with module capabilities, and manage the relationship with end users. In some projects, key users are also included in the structure. Some of these users lack sufficient experience with sample cases. And because proper user profiling cannot be done during projects, things start to get really messy.
In fact, one important issue is that over time people forget why the project was started. Strictly speaking, projects should be carried out to obtain the required official and unofficial reports. For this, stakeholders should define measurement criteria with concrete figures at the start of the project and apply them throughout.
When you add to this "the difficulty of satisfying all users", "almost no mobile use", and "user needs changing over time", running a successful project unfortunately becomes harder and harder. Especially when key users change jobs over time, organizations can be left with a pile of screens, features, and integrations whose purpose is unclear. At this point, the love story suddenly turns into a hate story.
I did some research but could not find success rates specific to SAP projects. From a project management perspective, 40% of projects worldwide end before even reaching the production environment. 30% of the rest run into irreversible problems during the project. 25% of the 52% that appear successful meet a "What is this?" reaction once they reach the end user. And 55% of all projects go over budget. I estimate that SAP implementation projects in Türkiye are a notch more successful.
So how should an SAP project be made to work? The platform is extremely flexible; it is, so to speak, the Porsche 911 of its field. So how does it go wrong? If your highways are full of potholes, the Porsche unfortunately cannot speed up.
This is where process platforms come in. The candidate platform should be able to talk to SAP in every respect, developments should be possible without writing code wherever possible, and processes should be traceable, measurable, and reportable. In short, it should be PaperWork. 🙂
PaperWork has an SAP connector architecture. This means that, without writing any code in processes, it can call business objects (BAPIs) in SAP, send parameters, and continue the workflow by receiving the data produced when the business object runs.
As in the sample screen above, the SAP connector sits in the workflow as an activity. After this activity is placed at the required point in the flow with drag and drop, the business object to be run on the SAP side is selected from a list. This list includes all business objects added on the SAP side during implementation. Once selected, the business object's input and output values appear in a list. From the list, you choose which workflow fields map to which input and output parameters. That's all there is to it!
With the selection, C# code is automatically generated in the advanced section of the activity. If you want to change incoming or outgoing data, or convert certain data types, you can modify the code in this section.
With similar C# code, workflow electronic forms can populate their lists from SAP business objects. Or a list retrieved from SAP can be shown to the user so they can make a selection. In short, any kind of SAP data can easily be sent and received across the entire PaperWork architecture.
Once connected to the SAP architecture this easily, PaperWork's features start to come into play:
. Processes are dynamic. When needs change, it is extremely easy to make changes to the process or electronic forms.
. Processes are traceable. You can track which process is at which stage.
. Processes are measurable. A KPI object can be used in PaperWork processes. With it, you can measure how long one or more work steps take to complete. These measurements can be reported.
. Time can be tracked in processes. That is, SLA times can be set for specific steps or for the whole process, and you can track whether work is done within these times. The actions taken can be reported.
. Process data can be reported. PaperWork has a report design interface. Dynamic reports can be prepared using all data generated in processes, including data sent to or received from SAP.
. Processes or certain tasks can be triggered automatically at various intervals. PaperWork has a scheduled job architecture and can automatically run a C# method according to a defined job.
. Processes can be managed from various environments. PaperWork offers a very rich variety of interfaces. There are web-based interfaces. Users can manage their workflows through native applications on iOS and Android. There is also a separate extension that sits inside MS Outlook and lets users manage their workflows.
In addition to these interfaces, there are SAP BPM interfaces, not yet finished and announced for the first time in this document. With this product, users will be able to manage all their workflows without leaving the SAP interfaces. Below is a sample screen of this interface.
May your projects that start with love never turn into hate…
Sources
https://www.ibm.com/think/topics/enterprise-resource-planning
https://www.ibm.com/think/topics/erp-integration
https://dergipark.org.tr/en/download/article-file/4071242
Would you like to see PaperWork in your organization?
Request a Demo
