He walked through a number of examples of what could be done with their library of available services, and showed a bit of the environment used for this; this ranged from automatically adding comments to work items to performing various sorts of calculations, which sounded as if they were things that have caused headaches (and custom coding) for their customers in the past.

As I’ve pointed out in my posts about the other sessions, this is not cutting-edge technology, but it’s ahead of where most of DST’s customers are in their technology journey. Existing AWD customers can be upgraded to AWD 10 without changing their existing applications, but that won’t allow them to take advantage of the new features that we’ve been seeing this week: to do that, they need to redevelop their applications using AWD 10. Design Studio definitely makes that easier, but that may not be a popular idea with customers who are happy with their existing legacy applications built on older versions of AWD that run just fine on the AWD 10 infrastructure.

Consider the different types of AWD customers:

• Customers for whom DST outsources at least part of their process and infrastructure, including “friends and family” (companies that are connected to DST through corporate ownership) as well as arms-length customers. These have, I believe, already been upgraded to the AWD 10 infrastructure, but for the most part are still running legacy AWD applications. These are likely to have their applications updated to AWD 10 on an ongoing basis, since DST has some degree of control over the application development and deployment.
• Customers who use other DST transactional systems such as TA2000, tightly integrated with AWD. These will undoubtedly be convinced to upgrade the infrastructure, but may decide to stick with their legacy AWD applications unless they can see clear reasons why they need to take advantage of the new functionality. Rewriting their applications will take time and holds some degree of operational risk, so they may stay on the legacy apps (although on the new infrastructure in order to remain supported) for some time.
• Customers who do not have tight integration between their transactional systems and AWD may also stick with their legacy applications; at the point that they are forced to upgrade (either because of support issues in the future, or because they need newer functionality), they may choose to evaluate other BPMS along with AWD. For DST, this represents a risk that they may lose a customer, or at least the BPMS part of their business, although the existing customer relationship may allow them to combat this.
• Customers with no other DST products besides AWD. This is a big risk for DST, since there is little reason for them not to evaluate other BPMS at the point that they need to rewrite their applications. This is also true for new DST customers where they are only looking for BPM/ACM, not the other transactional systems, as they are more likely to find outside North America where the DST transaction processing systems are less commonly used.

DST has a lot of low-hanging fruit in the first two of these categories, and the existing relationship will probably see them through a lot of the third. However, the BPMS-only customers are going to be the challenge, since they will be selling AWD against other BPMS that are further along the technology curve. They do have some strengths, but their biggest strength by far is their existing customer base and the close relationships that they have with those customers.

That’s it for me and AWD Advance; this has been a really interesting view into a very different sort of BPM vendor, and I look forward to seeing how their technology matures and the path of their customers in the future.

Back to business, however, I’m in the technical session on AWD monitoring and business intelligence, following on from Kim Smyly’s introduction to the new monitoring yesterday, where Dirk Luttrell and Bob Kuesterteffan are giving us a peek under the covers for their new monitoring offering. They are implementing dimensional data modeling in their new offering – which, as I pointed out yesterday, is based on Oracle’s BI – in order to provide better business-based metrics and analytics. We got a brief tutorial on dimensional data models (star schemas in relational databases, or cubes in multidimensional databases), making me wish I was paying a bit more attention when my other half was talking about how he was implementing one of these in his data warehouse. In short, relational data models are organized around transactions, whereas dimensional data models are organized around business entities and information. Business entities are represented in fact tables, and dimensions are key to selecting, sorting, filtering and summarizing the data contained in fact tables.

The core AWD data is based on relational models, since it is a transactional system, but both the process and line-of-business data in AWD can be published to the dimensional (star) model for easier reporting and monitoring. If you’ve ever written a report or dashboard based directly on the process transactional data in a BPMS (which I have), you know that it’s not pretty: BI tools are optimized for dimensional data models, not relational transaction models. In the past AWD has allowed for reporting directly against relational models, but it was (is) not very flexible and could be prone to performance and scalability problems, requiring either extremely complex (and compute-intensive) queries, or denormalization and data duplication. Furthermore, it requires that report writers know and understand the underlying relational data model since they’re writing directly against that physical schema, which further locks in the core AWD product to that schema rather than being able to mask it behind a logical data schema.

In the new dimensional data model, they represent business entities directly: work items, queues, users and various other attributes of work including time dimensions. They also include a single line-of-business data dimension for all LOB fields (this seems like they are relational-izing their dimensional model, but I can understand the administrative and design complexity if they didn’t do it this way), so that fields such as account number can be used to cross-reference to other systems or for filtering, searching and sorting within the BI context.

They are creating the following fact tables:

• Assigned work fact, with dimensions regarding when and to whom a work item was assigned and unassigned, and the current state regarding assignment and work selection. This is used, for example, to report on assigned work by user.
• Completed work fact, which tracks work steps as they are completed, including duration, user experience level and other information about how the work was completed. This is used for reporting on work that was completed.
• Locked work fact, tracking items when they are locked by users: who, when and how. As with assigned work fact, this is used for reporting on work locked by a particular user.
• Login status fact, tracking when users log in and out, and whether they are currently logged in.
• Queue fact, tracking work as it moves from queue to queue, and the status that each work item is in.
• Suspended work fact, including when items are suspended and unsuspended, and who did it.
• Work fact, which including historical information on work but includes a “current” flag to filter for just work that is in flight.

[This is probably way more detail about their dimensional data than you’re interested in, but I blog because I have no memory, and this is my only record of what I see here. That’s right, it’s really all about me.]

Given that the same underlying relational model will still be there in AWD, customers can continue to use the existing AWD BI (which would hit against those tables), but I’m guessing that a lot are going to want to move over in order to take advantage of the ease of use, performance and scalability of the new BI environment. They’re also planning on some future features such as scheduled report delivery; I’m not sure which of the new and upcoming features are based purely on the underlying Oracle technology, and how much that they’re building themselves, but if they’re smart, they’ll leverage as much of the Oracle BI package as possible. They also need to figure out how to integrate/publish to enterprise data warehouses, and work up full replacement functionality for the current BI product so that it can be retired.

DST is in the process of rewriting the user management functions, and Angela Veach and Arti Acharya (the experience designer) presented the wireframe designs in progress. This is greatly simplified in terms of the number of screens and in terms of the language used on those screens, such as:

• Create a new user, specifying general attributes such as name, user ID, security level and work group. This can be done using another user or a model user as a template, such that privileges, experience levels and resources are inherited from the model.
• Manage what they can work on, by assigning one or more roles, assigning individual privileges such as specific business areas or work types that are beyond the capabilities of the assigned roles, and assigning experience level.
• Manage what they can see in AWD, by assigning security group, and additional individual resource access control grouped by product/capability.
• Specify resource-specific attributes, which are the additional parameters required for the different capabilities to which they have access, e.g., the signature that will be used for correspondence generation if they have access to the correspondence capabilities.

They’re still working out the details on this, and are actively soliciting ideas from their customers in the audience. There are a lot of options here, such as whether selecting a model user should replace or augment the existing privileges on a user account.

This appears to be a new interface on the existing structure of users, roles, skills and permissions, rather than a new underlying structure, meaning that it doesn’t impact much in terms of operational functions (except a new dialog to select their primary workspace if they have been assigned to multiple), mostly just these administration screens. There is a still a very complex structure that needs to be well-understood by an administrator, but at least the administration screens will make it easier to implement. Lots of happy sysadmins in the audience.

As with case management, this is unreleased functionality still under development, likely to be released in 2013.

This was the last session of this first day of AWD Advance 2012; we’re off to the reception and conference dinners tonight, and will resume tomorrow. I have been assured that dinner will not involved Lipizzan stallions or palaces, although I might see a cow sometime before I leave tomorrow.

She described case management as a new application or user interface, meaning that the AWD 10 BPM capabilities are there as part of it, but it has additional capabilities such as collaboration, content, ad hoc processes and deadlines. This circles back around the ongoing discussions in the industry about the relationship between BPM and ACM; certainly, process is a part of ACM (even structured process), but it’s more than that. They did research with their own BPO companies and some of their customers spanning retirement, mutual funds, insurance and healthcare industries, and came up with four design imperatives for a case management solution:

• A humane way of working with files
• Reorienting yourself to a case: making it easy to pick up where you left off after some time away from the case
• Immediate responsibility versus ultimate responsibility: understanding ownership and responsibility for meeting milestones
• A system that suggests rather than dictates: supporting the knowledge worker rather than enforcing a specific process

The primary workspace now for knowledge workers (as defined in their profile) is a dashboard listing their top 10 tasks – as defined by what they own and due date – and a task forecast for the next three weeks, then their top 10 cases and the case workload of all members of the worker’s team. There are two other tabs for cases and tasks; on each of those are interactive filtered views of the cases and tasks in progress. Both cases and tasks are types of AWD work items (with a predefined process model, even if just a single-step user task), with tasks being children of cases; opening a case or a task takes you to a view of that work item with the related data, content and activity. Tasks can be added to a case by the worker, using a template, and content can be added at the case or task level. Messages get passed around between cases and their tasks to allow for processes to be started, paused and rendezvoused appropriately. Cases can be created from templates as well, where a case template contains one or more tasks of any degree of complexity. Both task and case templates are, in fact, templates: if they are changed, work that is already instantiated is not impacted. Furthermore, cases can be organized into folders as a collection mechanism, although folders are not routes as cases and tasks are.

This is not yet a released product: it’s scheduled for the end of 2012 or the beginning of 2013, and they are currently researching different representations that they might create of manager and team views, as well as reporting on knowledge work. This latter issue is one that I’ve been talking about a bit lately, and proposed it as one of the “unanswered questions” in my presentation on the nature of work at last year’s academic BPM conference.

This is pretty standard BI in terms of report and dashboard definition: quite a bit of flexibility for visualization and computation in a drag-and-drop interface, no more difficult to use than Excel tables and charts. It includes pivot tables (which you may know from Excel), which are great interactive analytical tools. I’m not sure what the legacy AWD BI looks like, but if it’s like that in most older systems (usually some ancient version of Crystal Reports), this is bound to be a huge improvement.

Line of business data can be included directly as fields in the dashboards and reports; I’m not sure of the underlying data architecture, but it appears that LOB data dimensions are defined in AWD and somehow replicated from other systems (or they are a view on those other systems); because they’re in the AWD data schema, they’re exposed for monitoring and reporting.

A number of questions from the audience on this; DST is porting over from the old to a new schema, and although they will support both for the foreseeable future, I expect that this will eventually force a migration from the old report mechanisms. It seems like the first implementation of this is not as powerful as the old custom BI (although probably significantly easier to use), so they will need to bring the functionality up to match before they can expect a mass migration.

A big chunk of DST’s core business is still with mutual fund processing companies, since they provide both the TA2000 transfer agency system (for transaction processing and shareholder recordkeeping) and AWD for the imaging, workflow, correspondence generation and other related capabilities. For those companies using TA2000, which is really a mutual fund industry standard in the US, the natural fit has been to use AWD as well since there is some deep integration between them, and DST is pushing hard to ensure that AWD 10 continues that tradition.

Their consistent message at their user conference this week is transforming business (through, of course, the implementation of AWD 10). Part of this is to treat transactions not just as independent transactions any more: many transactions represent life events such as births, deaths, marriages and divorces. How you handle the transactions related to a life event – which usually required initiating and managing transactions and tasks that the customer didn’t think of – can make or break that customer relationship, and that viewpoint can be transformational for how you run your business. This requires a case management approach to that life event, where directed dialogs (wizard interfaces) collect information that can be used to spawn additional tasks required for case completion.

They’re also enabling additional transparency by allowing financial advisors – those people and companies who actually sell the mutual funds – to participate directly in an existing AWD workflow through the DST Vision portal application. For mutual fund transactions, this is primarily to report on transactions that are not in good order (NIGO) so that the advisor can provide additional information in order to complete the transaction, usually related to transfer of assets. This presents a filtered view of the back office information, since advisors are not permitted to see all information about shareholders and transactions, and may include images of the original documents provided.

It’s difficult to tell how well the transformation message is going over with the customers, but based on the audience questions, the functionality provided by DST Vision is much more relevant to them right now. Although all of the DST full-service clients (that is, those where DST or one of their related companies are doing some or all of the processing) are operating on the AWD 10 infrastructure, that doesn’t mean that they’re using the emerging capabilities, and the self-serve mutual fund clients in the room may be slow to follow.

• Inbound scanned documents, faxes, emails, tweets and other sources
• Forms builder for data capture user interface
• Process design (apparently with BPMN), including service calls and subprocesses
• Work assignment
• Audit and quality review history
• Correspondence generation, based on templates for standard parts of the letter, and allowing for ad hoc text
• Integration with customer database and business rules
• Monitoring dashboards for individuals and teams

I’m not seeing any unusually innovative BPM capabilities in AWD 10 compared to other BPMS, but this reminds me a lot of how BPM is presented at SAP conferences, for much the same reasons: these customers are using DST products that run their current business effectively, and the agile process-centric BPM environment is new (and likely a bit scary) to them. However, by focusing on things that really matter to these BPM newbies – transaction processing, ability to quickly change process models, quality, work monitoring – they’re showing the inherent value in a more flexible environment over their older AWD code-driven environment.

The challenge for DST will be whether these customers will make the jump to AWD 10, or decide to evaluate other BPM systems if this is a complete application rewrite from existing AWD platform versions. If there is a great deal of customer loyalty, or the customers are bound to other DST systems that will integrate more easily with AWD 10, this may not be a case of offering the best BPMS on the market, just the best BPMS for existing DST customers.

John Vaughn, VP of business process solutions, gave the opening keynote about business process and customer experience as competitive differentiators: if you do it better, and make your customer while you’re doing it, you have a killer combination. If you read about my experience with Zipcar, you’ll know that this is true. Competitors in the future aren’t necessarily going to be who you think they are now; they’re going to come from places that you don’t expect, in terms of geography, company size and current industry focus. DST’s customers here today, many of them financial services and business process outsourcers, aren’t going to just be competing with other current financial services and BPO companies: at some point, Walmart is going to start selling mutual funds, free agents are going to develop financial planning software, and China’s going to ramp up their outsourcing capabilities. All of this is going to be seriously disruptive for companies that aren’t expecting to compete outside their current base of competition.

AWD as a product has been around for 20 years, and I expect that many of the customers in this room are still on older versions, wondering why they should convert from the old system that runs their business perfectly well to something new and potentially risky. This disruptive business and economic environment is exactly why you can’t just upgrade your server and keep doing business as usual.

Lisa Williams, officer of product management for AWD business process solutions, followed on from that to talk about where they’re taking AWD in the future: empowering knowledge workers, customer engagement through mobile and social, and generally enabling business transformation. AWD 10, which we’ll be hearing more about later today, provides a lot of capabilities to move this forward, but you also need to consider reinventing the customer journey rather than just incremental improvement. Then, you can use the AWD 10 capabilities that you already have to implement that platform to engage your customers.

Mike Lovell, director of product management, finished up the opening keynote with a focus on supporting knowledge workers by getting the technology out of the way and allowing them to engage with the customers. Productivity, throughput and quality are table stakes with AWD, and will never be compromised; rather, you need to up the ante with case management for a more flexible yet powerful environment to support those workers with prioritized task lists, activity feeds and team collaboration. There are also new monitoring and analytics capabilities for better visibility and more intelligent processing.

Good kickoff to the conference, and lots of interesting things to come.

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.

They handle a variety of input channels and devices: scanners (including check scanners), MFPs (“Mit Netzwerkanbindung”, according to the slides ), 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.

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.