From Adobe Forms to Multi-UI processes

[chris_scott]

PDF forms have enabled many SAP customers to automate manual processes, remove paper forms and replace processes based on Excel/Word forms that require manual re-keying.
However, many form-based processes involve multiple processing steps, such as levels of approval, and these steps might be processed on a multiple of devices, where PDF is the wrong user interface or where the version of Adobe Reader does not support Interactive Forms.

The solution might involve a complex mixture of interactive forms, portal pages, mobile apps and even SAP Fiori, as one size does not fit all.

• Portal pages based on BSP or web Dynpro can have limitations with mobile devices.  SAPUI5 is a much better alternative, but it takes a lot of extra development to create a SAPUI5 page that works on many devices.
• Custom mobile apps overcome this issue, but they can be expensive to maintain.  Plus, users do not want to manage many mobile apps on their devices.
• SAP Fiori has the advantage of acting as a container for multiple simple transactions, but users will not want to manage many tiles within SAP Fiori, and the standard transaction screens delivered within SAP Fiori will often not fit the business requirement closely enough.   Plus, SAP Fiori works only ‘on-line’ whereas custom apps can be developed to work off-line and synchronise data later.

Moreover, for many business processes, you do not know what device the user will use at each step of the process.  Processes may be triggered from desktop or mobile device, and approved in the office or on the move.  Users will have multiple devices and it is not realistic to expect them to install and manage a range of apps on a range of devices.

Let’s consider a simple real-life example.

Company A has 10,000 employees, all of whom have access to ESS.  Within ESS each employee is empowered to update their own personal data such as home address, next of kin and bank details.  The problem is that they don’t.  Many users only have a SAP ID for ESS access, and they don’t use it as they have long forgotten their password, or don’t realise that SSO is in place.

This leads to a variety of issues for Company A, with a high HR administration cost.

Company A also has 2,000 temporary employees who have employee records but no ESS access.  The personal data for these employees is also incomplete or incorrect.

No combination of mobile apps, SAP Fiori and portal pages is going to fix this issue: it is one of process compliance, and that’s where a forms-based process can add huge value.

A possible solution could be:

• Process triggered by HR Admin, Manager or background job
• For each selected employee a form is generated and they are sent a notification e-mail.
• For employees with no SAP access, or with no recent activity in the SAP system, a PDF interactive form is attached to the e-mail.  This is pre-populated with their own data which they can confirm or correct and submit back.
• For employees with active SAP users, then they can be presented with a link to an on-line version of the form, which can be rendered in HTML5, so that they can use any device to check and correct their own data.  Alternatively they can use ESS (or a custom app) to update their data.
• When a form is submitted back then the employee data is automatically updated.
• A background job can check for any unprocessed forms –and check whether the employee master record was updated – and if not, then trigger a reminder e-mail.  As time passes the employee’s line manager can be informed:  The system can ‘chase’ each employee until they have confirmed their own data.

So here a solution involving multiple UIs and many devices can solve a business problem without a large scale roll out of mobile apps or SAP Fiori.

Let’s consider another example:

Company A is processing a mixture of expense forms. Some employees are using an Excel spreadsheet, some are using SAP Portal.  Some employees are scanning receipts, others are posting the receipts.  It’s a mess.

The company wishes to introduce an expenses mobile app, whereby the employees can enter details and attach photos of receipts, taken on mobile or tablet.

As part of the expense form, the employee indicates the project or cost centre against each item, and then approval for those items has to be sought from the budget owner.

In some cases the form will need to be approved by a line manager or by an administrator to ensure receipts have been checked.  This might be a dynamic rule based on the form data or simply a governance rule (such as 5% of expense claims must be randomly checked).

Not all users will have mobile devices and not all users will have SAP access.   Users will want to be able to track the progress of their expense form through approval stages.  At any time the expense form can be rejected back to the user.

Users can be notified by e-mail and SAP Universal Worklist, and so there isn’t any value of adding an ‘inbox’ function within the expenses app.

Users who submitted expenses claims without using the app also need to track their forms, and so there isn’t any point in building the tracking capability into the app either.

So quickly we see that the best fit is, once again, a multi-UI process.

With a multi-UI process, employees with SAP access could elect to start the process using an on-line form, the custom mobile app.  Employees without SAP access could either be sent a PDF form each month, or could download a PDF form from the company intranet, or could use a published html form on the intranet.  The benefit of sending the form to the employee is that it can be pre-populated with their own data.

Wherever the form was submitted from the rest of the process should now be common.  Data from each form will be collated by cost center / project and routed to each budget holder for approval.  Only when all parts of the form have been approved will the form be moved on to the next stage of the process.   Users will be notified by Universal Worklist, E-mail or both.  Off-line users will continue to work with off-line forms. On-line users will work with on-line html forms.

The point for organisations to consider when introducing new UI solutions is that the mixture should be the norm. They should not design a single new process and manage all exceptions separately: the management of those exceptions is where a lot of hidden cost lies.  Designing the process first and the technology second will result in a better business fit, and greater overall process efficiencies.   I caution against selecting ‘web Dynpro’ (because that’s what we always do) or ‘SAP Fiori’ (because that is what SAP are selling us) or ‘custom app’ (because users are crying out to use their iPads).  That’s no way to start a project.

Some simple forms infrastructure, like Arch FLM, will provide the framework for easy development and management of multi-UI processes.  FLM provides common form services, such as device determination, pre-population, data validation and form routing, which can be re-used by a variety of UIs such that organisations can maintain their business logic centrally instead of replicating it to support each different UI.

When organisations adopt a multi-UI approach they future-proof their business processes from changing UIs.

Arch FLM is a SAP-endorsed business solution.

SAP-endorsed business solutions are complementary to SAP® software offerings, have been specifically integrated with SAP solutions and tested by SAP, and provide additional choices and flexibility for businesses running SAP software. SAP-endorsed business solutions are offered by SAP partners.