Document Capture to Process

The second half of the morning at ISIS Papyrus was a pair of sessions on document output and document input, or as the session titles put it, “unified print, web and mobile output management” and “scan to extract to process”. The first was a great deal more information on yesterday’s session on correspondence generation, and you can check out their website for more information on the features and functions.

The second session, on document capture, started with business drivers for capture and scanning, particularly the link from capture to process. A lot of organizations are doing capture to archive, but a smaller percentage are using recognition technologies (classification and extraction) or triggering processes from the documents. Interestingly, a much larger percentage are using document classification (i.e., what type of document is this) but not data extraction (i.e. what customer-specific information is on the document); there’s a big ROI just in document classification without additional recognition since that can be used to automatically route documents to the right department for handling.

ISIS recognition architectureThey handle a variety of input channels and devices: scanners (including check scanners), MFPs (“Mit Netzwerkanbindung”, according to the slides Winking smile ), fax, email, camera phones, social media and file import. I had a demo yesterday of their recognition and extraction capabilities, and it can be applied to both structured forms and freeform documents. A typical capture path includes steps for rearranging, splitting and merging (often for fax documents, over which there is less control on the input), then document classification, automated extraction and validation, then manual verification and correction. In this way, they provide the same functionality as products such as Kofax or IBM Datacap.

Document classification can be based on layout (fixed format), keyword (text or barcode) or text-based (phrases), and their capture design environment allows for learning by example to create any of these. 2D barcodes (which may have been generated by their outbound correspondence module) can be identified and used to match an inbound document to an existing case.

There are a number of administration and monitoring capabilities to track how many documents/batches have been captured and where they are in the processing queues.

They have a number of customers that are capture only – this, in addition to correspondence generation, are two of their key use cases – but provide greater added value if the capture process leads directly into distribution and case creation/management.

ISIS Papyrus Adaptive Case Management

ISIS Papyrus defines (and implements) ACM as the full range (dare I say, a spectrum?) from straight through processes through dynamic processes to completely unstructured process driven by ad hoc content arrival such as email or social media. This, I believe, is at the heart of discussion/argument about BPM versus ACM: this definition has traditional structured BPM as a subset of ACM at the structured end, with ACM covering a much broader range of structure as well as being inherently content (document) centric, and including a number of additional capabilities such as goal orientation and business rules.

At the structured end, this can be fully automated service orchestration, driven by events or by (document) state: this can be modeled as a flow diagram, but the individual tasks are adorned with additional information about state and events that impact that task, such as a task firing when a document reaches a specific state.

At the unstructured end, this provides a collaborative case-oriented environment for a knowledge worker to manage a response to some sort of inbound content, including integrated correspondence management based on the core technology that we saw in detail yesterday.

In any type of application along the spectrum, but especially at the unstructured end, you can have access to social media channels (both inbound and outbound) as well as data from other systems and related documents. External events can impact the case, and business rules created in natural language can be applied to constrain or act upon the case. Tasks within cases are linked to goals, as defined in the business architecture; goals can be linked, and sub-goals defined for more structured dependencies. The system learns as more cases are processed relative to their goals, allowing for the next best action to be suggested to the user on a case based on the history of similar cases; this could, of course, be applied in an automated fashion rather than as a user suggestion, but this level of machine intelligence tends to make some organizations uncomfortable.

Although processes can be represented as flowchart-style models, they can also be represented as Gantt charts (or PERT charts, for that matter) to be able to visualize the critical path through the process and provide some predictions around due dates for various milestones. I’ve seen this representation from other vendors, most noticeably BP Logix, for whom I’m writing a white paper on predictive analytics and the importance of adding a time dimension/representation to processes.

There is a task-specific user interface for the details portion which must be customized for each task type, although the framework includes standard information such as a history of the case activity and resources. The task interfaces are developed using widgets, and a single UI definition can be deployed on any platform (including mobile) without customizing specifically for that platform. A mobile deployment environment is becoming critical in application development, as we saw last week at IBM Impact with their focus on using their Worklight acquisition for mobile development and deployment.

They’ve created the critical round trip between strategy and execution by connecting strategic objectives (in a strategy map) to business architecture (in a capability map) to process goals (balanced scorecard and other KPIs): not only is this top-down, where strategy defines capabilities, which in turn are used to define KPIs, but also feeding back so that the actual performance during execution is compared back to the architecture and strategy.

ISIS Papyrus stresses that ACM is just a capability of their content processing platform, and I think that this is part of the confusion around the definition of ACM: ACM is about how we do work, so requires a combination of activities, content, rules, user interface, and integration with external systems. However, there are a lot of application development environments that provide some or all of that without being defined as ACM, and more traditional BPM products are redefining themselves as ACM by adding some of these capabilities even if it’s not a good fit with their underlying infrastructure.

The ACM market is still emerging and will continue to evolve. Having some good examples of ACM in action through the ACM Awards (for which I’m one of the judges) will help with market understanding, but I anticipate many more discussions on this topic along the way.

Mobile, Social And Integration With The Papyrus Platform

Day 1 of the ISIS Papyrus open house was more about their capture, document processing and correspondence generation, which is what many of their customers are using. Today, the focus is more on newer functionality, and we’re starting with Roberto Anzola, senior manager of R&D, discussing their mobile and social capabilities.

They provide a mobile app that acts as a portal to any application developed on their platform; Forrester has recently identified this functionality as “mobile backend as a service”, where the application is defined on the server, not on the device, and accesses data and user interface components from the server. This provides access to the same application on iOS, Android, PC desktop and in the browser through their UI widgets. The mobile server supports SOAP and REST calls, as well as OAuth for authentication on social networks. The app provided for the conference (which you can find on the iTunes app store by searching for ISIS Papyrus), is built on their mobile server technology. We saw a demo of an iPad-based vehicle claim app built on this platform, and how the menus and features on the app are driven by the case definition in the desktop environment. Because it’s driven by the Papyrus platform, the app has access to the same data and documents as a desktop application, although rendered in a mobile form factor.

He went through a number of different integration points that they have with other systems:

  • Access to LinkedIn contacts for inclusion in an application.
  • Detecting and responding to Twitter messages (as we saw yesterday)
  • Set and retrieve events in Google Calendar
  • Use Google Translate to translate text building blocks in the designer, or on the fly for dynamic case information
  • Use SharePoint as a document repository for documents linked to a case as well as exposing cases within SharePoint using Papyrus WebParts
  • Integrate with SAP (and many other systems) using web services
  • Direct file system integration, where case data objects can be exposed for navigation directly in Windows Explorer if that is a more natural interface for users rather than using Papyrus directly, although it wasn’t clear how access control to the files is managed
  • CMIS access to any standard document repository, including EMC Documentum, IBM FileNet, Alfresco and SharePoint

Although the title of the session was about social media, this went through a much broader set of integration capabilities, as well as the mobile platform.

Personalized Electronic Statements at China Trust Commercial Bank

We’re running 30 minutes late and it’s right before lunch, but everyone is sticking around to hear Ignatius Chang, EVP at China Trust Commercial Bank, talk about their initiative for statement e-delivery. Based in Taiwan, they are in an overcrowded financial services market, and technology has become a competitive differentiator for them in customer retention through superior service. They have about 5 million credit card holders, and send out over 2.5 million statements per month. These statements aren’t just a statement, however: they include targeted promotional information and offers for other products and services in the same document.

Their move to e-delivery was driven by some basic business goals: they wanted to reduce print and post costs by moving customers to e-statements, but maintain the personalized marketing and visual appearance of the printed document without generating a PDF. They wanted a common document design and handling process for both paper and electronic, although electronic required additional features such as secure encryption and support for mobile devices. Since the statements included marketing campaigns, they wanted to be able to track the campaign response rate, since this contributed to their return on investment (in addition to the cost reduction when moving to e-statements).

They are only partway along their journey with the Papyrus platform, so some of this described future plans rather than current reality – it will be interesting to see how they achieve their goals as they continue to implement in the future.

Integrating Inbound and Outbound Correspondence

In the previous session, we heard a lot about the ISIS Papyrus correspondence generation capabilities, but it’s important to look at response management, that is, closing the loop with inbound and outbound mail. This has to be considered in two different scenarios: an inbound customer interaction (paper, email, telephone, social media) triggers an internal process that results in a response interaction; or an outbound document solicits a response from a customer that must be matched to the outbound request. Response processes can be fully automated, manual, or automated with user intervention, depending on the degree of classification and content extraction that can be done on an inbound document. Not only does it handle the entire response management process, it provides analytics, such as campaign responses.

Their capture components include classification based on layout, keywords and/or barcodes; and data extraction from fixed forms or freeform documents. I’m not sure if this is their own recognition software or if they OEM in someone else’s (I suspect the former, since they seem to be doing a lot of innovation in-house), or how the accuracy and throughput compare with market leaders such as Kofax and IBM Datacap.

Once the document is captured, classified and the content extracted, a response letter type can be selected automatically based on business rules or manually by a user, then completed either automatically based on the content of the inbound letter, or with user assistance.

There are specific social media capture functions, such as the ability to track a Twitter hashtag, then analyze the sentiment and open a case directly from a tweet. If the user is identifiable, it can cross-reference to customer information in a CRM system, then present all of the information to a user to follow up on the request or complaint. This is exactly the sort of scenario that I imagined happening internally at Zipcar during the interaction that I described when talking about linking external social presence to core business processes.

If you consider the business scenario, it’s a real winner for handling inbound customer correspondence. First, an inbound document is received, analyzed and routed based on the content, including things such as looking up or extracting customer information from other systems of record. If some manual intervention is required for the response letter, a CSR is presented with the inbound letter, the generated outbound letter, customer information from other systems for context, and instructions for completing the letter. Inbound correspondence can be anything from a paper letter to a tweet, while the outbound can be the channel of choice for that customer, whether paper, fax, email or others.

Business Communication Platform for Correspondence Generation

Annemarie Pucher, CEO of ISIS Papyrus, discussed having a business communication platform for handling personalized content. Rather than having multiple systems that deal with content – ingestion, analysis, processing and generation, multiplied by the number of interaction channels – a single platform can reduce the internal efforts to develop content-centric processes, while presenting a more seamless customer experience across multiple channels. This is particularly important for personalized outbound documents, whether transactional (e.g., statements), ad hoc (online presentment), or as the result of a business interaction (e.g., contracts), since the customer needs to be able to receive the same information regardless of which interaction channel that they choose.

She discussed how their platform provides fully personalized outbound correspondence based on composing documents from reusable elements rather than a simple mail merge approach. The building blocks may be sections of text, graphics, 2-D bar codes and other components, which can then be assembled in different ways based on rules that consider the customer information, the geographic region and other factors. Different language versions of each component can be created. The document assembly can access business information from other systems through a variety of adapters, and interface with different input and output channels. Business people can create and modify the building blocks and the overall document template, allowing them to change the layout and the dynamic content without IT intervention, although IT would be involved to set up the adapters and interfaces to other systems and services.

For interactive correspondence generation, such as what would be done by a customer service representative in response to an inbound call, they provide in-document editing of the dynamically-created letter. This allows the user to type in information directly and select which sections of the document to include, while ensuring that the predefined content and rules are included in the format required. There can be a complete workflow around interactive correspondence generation, where certain changes to the content require approval before the document is sent to the customer.

Regardless of whether the document is created interactively or in batch, that single document can be rendered to multiple output channels as required, including hardcopy and a large variety of online formats. This can include functions such as pooling for combined enveloping (something that I wish my brokerage could learn, rather than sending me multiple confirmations in multiple envelopes on the same day), confirming that a printed document was sent, and handling returned paper and electronic mail. Supporting CMIS allows them to store the documents in other content repositories, not just within their own repository.

We finished up with a demonstration of creating building blocks in their Document Workplace, then assembling these into a document template. The workplace is similar in appearance to Microsoft Word from a text formatting standpoint, making it easy for business people to get started, although there’s quite a bit of complex functionality that would require training. Although no technical skills are required, it does require some degree of analytical skills for designing reusable components, handling variables, and understanding document assembly parameters, so may not be done by the average business user.

I haven’t spent a lot of time reviewing correspondence generation capabilities, but it’s something that comes up in many of the BPM implementations that I’m involved in, and typically isn’t handled all that well (if at all) by those systems. In many cases, it’s a poorly implemented afterthought, performed in a non-integrated fashion in another system, or becomes one of those things that the users ask for but just never receive.

Focus on Customer Experience with @maxjpucher

Another week, another conference. Instead of 9,500 people in Las Vegas at IBM Impact, however, this week I’m amongst a group of about 200 in the outskirts of Vienna for the ISIS Papyrus open house and user conference. Last night’s conference event included Lipizzan stallions doing dressage set to music, dinner in a palace, and Viennese waltzing to a string quartet. The conference itself is held in the ISIS Papyrus offices, full of natural light and greenery. About the only thing in common with Impact and Vegas is that the wifi is misbehaving, bumping me offline for most of the morning.

The first day opened with Max Pucher, CTO of ISIS Papyrus, talking about the necessity for a focus on customer experience, and you need to invest in technology to empower your workers, not replace them. Customer experience – and brand loyalty – is heavily influenced by the customers’ interactions with your people, not just your products. Understanding how systems of engagement work with systems of record is key, and brings focus on the number of different systems that you use in order to conduct business; this array of technology actually makes it harder to enable change, since there are often very rigid interfaces between them.

He maintains that you can’t start transforming your business with the process: you start with people, then planning, then programs, then projects and finally process. In understanding the systems of record, it’s important to start with business architecture to define objectives, map those to capabilities and end-to-end processes: the business language of process. Then, business information can be mapped to the underlying systems, and business transactions can be modeled as services against those systems. The true flexibility, however, needs to be in the systems of engagement: this is where business people need to be able to adapt processes to meet the needs of the customers.

He finished up with a bit about their product: the Papyrus platform started as inbound/outbound content management, including content-centric process management, and has expanded to include capabilities for adaptive case management (ACM), business process management (BPM), process analytics and more. The product positioning is as an integrated system of engagement, interfacing with systems of record, but providing adaptive processes that can be defined and modified by the business. Although initial projects to establish the infrastructure and environment require IT, the idea is that once it is set up, the business can work within the case structure to define their own customer engagement models.

The core functionality, and what seems to be the sweet spot for many of their customers, is inbound and outbound document processing, although this is much more than just scanning paper documents and generating correspondence: it’s ingestion of content from a wide variety of sources, the case management capabilities required to process that content, business rules to constrain and inform the case, and a significant amount of pattern recognition and machine intelligence to provide automated recommendations for the next best action to the user along the way. Work in a case is structured around goals, with activities identified (either up-front or on the fly) that are required to fulfill each goal. The goals, in turn, are linked to strategic objectives in the business architecture as well as tactical targets (KPIs). All of this is within a single integrated system, meaning that you don’t need to worry about integrating content ingestion, case management, business rules, analytics, correspondence generation and other functionality.

Although Max and I have been sparring engaging online for a few years, this is my first real introduction to the ISIS Papyrus product, and I’m looking forward to learning more about it over the next two days.