Several weeks ago I had the opportunity to spend two days to catch up with the Adobe LiveCycle platform. Today I want to spend some time on what I would like to call ‘Room for Improvement’ for Adobe on their solution for eForms.
Before going there I must admit that there is Room for Improvement on my side when it comes to “SAP Interactive Forms by Adobe” (Interactive Forms). In a months time I will take care of this by attending my first ever SAP event. Today my knowledge of SAP doesn’t go further then knowing how to spell it. 
Until then I will only focus on here LiveCycle with the forms module as the centre of their universe.
First, my definition of what I mean by forms:
A form is a means to capture data in a structured way in an a-synchronous interaction between the human data provider and the receiver.
A client-server application for data entry is thus not using forms to collect the data. The data entry is done via a graphical UI that may look like a form though.
When do I consider the usage of forms over that of a plain old web application with data entry screens? By definition this would be the case when there is the requirement to support a-synchronous data capture. Requirements that are closely related are: local storage, off-line usage, on-demand processing (instead of batch processing), event driven processes, multi channel, ad-hoc and tailored capture as well as casual and untrained users.
Other considerations would be: extending an existing CRM, ERP of ECM environment, interaction inside the forms and leverage the existing desktop footprint.
When I refer to multi channel, I’m thinking of a mixture of keywords like: print, bar code, scanner, email, attachment, http(s), browser, web service, (s)ftp, upload, file share, webdav, mobile phone, pda, phone, call script.
Most of these I have seen in relation to LiveCycle Forms. The call script may seem an outsider. Most (if not all) forms can however be fully supported by a call centre agent calling the person that needs to provide the data.
Along these lines I have been thinking on where LiveCycle is heading wrong, is missing something or needs improvement. Needless to say however that LiveCycle is a good product when you e.g. want to extend your existing ECM implementation.
Let’s first address the going wrong bit. The current pitch is the Engagement Platform. A 100% bling-bling approach. It’s superficial. It’s all about the outside, the looks. The truth is, that it hurts the average business user at the weakest spot and thus is/can be successful. So, why blame Adobe for this? Because long-term it fits into the category “Shareholders Value” rather than “Customer Satisfaction”. Does it make the business process better? No, there is no increase in key factors for sustainable business. Or does America’s Next Top Model do a better job than Uggly Betty?
The last thing I will mention about this is that I personally find an approach that has its focus on the looks rather than the content questionable. My no.1 question becomes: what are they hiding?
Next: what is missing? The short and easy answer is: context and form generation.
Let’s look at context first.
For me this is important because we don’t live in the dark ages of forms any more. A from is not created because we want to digitize a paper form. The sole reason should be because somewhere in a business process there is a need for structured data capture. That is: IN A CONTEXT.
How do LiveCycle Forms support context? They don’t. This touches on the disconnect for the LiveCycle platform with how core systems (BPM, CRM, ERP, ECM etc.) become more and more interdependent. That’s why I do expect more from the Interactive Forms. These forms already understand SAP data models. At least that is my understanding today. Aside from this SAP integration all others need to be developed. Nothing strange for an add-on product but it is more convenient if Microsoft would offer the product “Microsoft Dynamics Interactive Forms by Adobe” and Oracle “Siebel Interactive Forms by Adobe”.
Another angle would be to become a provider of ECM, BPM, CRM and ERP altogether. That is however a direction that doesn’t fit in the strategic directions of Adobe (at least those that I’m aware of).
The second is Form Generation.
Form generation is a way to make the creation of forms a true business user activity. I can’t help but laughing out loud when the Designer is positioned for business users. It does require an IT background in order to do data binding and script simple business logic behind the fields. Business users won’t do. But then, who will be designing the forms anyway? I think there are largely 2 kind of forms: standard often used forms and ad-hoc forms. The first group is worth while to design up front and spend some design time on. Business users will be involved during requirements specification and user acceptance. No involvement in building the form technically.
The other group of forms are those that are created because the need arises suddenly. Almost for sure the content of these forms do change from case to case. The easy way out here is to ignore forms and just send a letter to te customer to provide the missing information one way or the other. Unstructured. The easy way out is appealing because creating a form is a burden. It takes days in stead of hours/minutes. Automated form generation will do the trick. And not only for the add hoc forms. Also for the main stream forms. There the development cycle will be dramatically reduced.
Room for improvement.
There are some area’s where I want to see improvement. These are: Recipient routing, Rules management, Secure attachment, Security at field level, Versioning at field level and pricing.
Let’s start with the last one. Pricing is a commercial aspect that I don’t want to discuss. Often there is more possible then pricing lists show. Still, I get the feeling that the list price is Enterprise Class only.
Next is recipient routing. What I mean by this is the ability to extend the routing of the form into the organisation of the data provider.
Imagine account opening where a company wants to open an account with some bank. Several forms need to be submitted. There is a single contact that deals with the bank within that company. But is this contact the one that retrieves all data? No! So the form is routed to other employees in the company. One by one. Most likely by email. Without tracking. Without control for the contact employee. Wouldn’t it be nice if the form could be put in a digital envelope that sends a copy of the form to all employees, have them completing their part and upon return merge the responses back into one form. Wouldn’t it be nice if the envelope knows which employees have returned there form and those that didn’t.
Rules management is an obvious one. Simply: how do I know which rules are used in this form and vica versa in which forms is this rule included. I don’t know. But I need to! Oh, and searching some database that holds the sources of the forms isn’t going to do. Let’s go a step further. What is the impact of changing a rule? Not just which forms are impacted but also which instances are in process and do need to be reconsidered before taking a decision.
Off course: I can built it…
Secure attachment is a less obvious one. In some cases the submitted form needs an attachment. A copy of an ID, another document. By default the returned form is now a high threat. I need to isolate the attachments, check them and continue only of the threat is gone. Basically this is so common – or at least should be – that this can be its own product or module in the LiveCycle platform.
Security at field level and versioning at field level. Two of the same. I want to be able to set security (who can do or see what) at one or more fields in order to protect their content. Also, I want to be able to track who changed the content of which fields. And in both cases I don’t want the coding option. I do want tick boxes to configure it.
As said, in no way I want to say that LiveCycle Forms are bad. I do say that there is room for improvement. There things that you can do but shouldn’t and it’s up to you to decide whether or not you do. There are may cases where they can be a valuable add-on. Taskspace within EMC Documentum is e.g. a useful solution for a Documentum implementation but it has its shortcomings that Adobe LiveCycle Form overcome. However, when there is a greenfield situation I would rather look at other options in the first place in order to avoid the need for an eForms add-on.
