Column 2

Simon James of DST gave what will be my last presentation of AWD Advance (in fact, I have to leave before the end to catch my taxi to the airport), looking at how services and automation are done in the Design Studio in AWD 10. This is a code-free (or code-light) environment for composite application development for process-centric applications. [Note to vendors: just because it’s done in a graphical environment doesn’t mean that it’s not code. Just sayin’.]

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.

Management of users, roles and groups in AWD is fully featured, but has its roots in functionality that was created decades ago. There are currently 15 different screens used to manage users, roles and groups in AWD today, and in many cases, they need to be visited in a very particular order to make something happen.

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.

My first post from the Gartner BPM conference in Baltimore this week; to be honest, there hasn’t been all that much so far that has inspired me.

Michelle Cantara, who focuses on organizational issues related to BPM, spoke about the roles required for successful BPM projects. She had four main points:

1. It’s difficult to find BPM-skilled resources: there’s a shortage of skills not just within some organizations, but in the market in general. In many cases, BPM is not a full-time job for someone within an organization, but a set of skills that they need to apply in the context of other work.
2. Not all projects require the same BPM skills sets. If you look at the Gartner BPM “sweet spot framework”, which is a quadrant with frequency of process change (low to high rate) along the horizontal axis and responsibility for process change (IT to business) along the vertical axis, they show three main usage scenarios for BPM (the lower left quadrant is considered not necessarily a good fit for BPM). In the upper left quadrant, for example, where BPM is used for standardization and manageability, process visualization may be a key skill that is not as important in the other quadrants. In the upper right quadrant, which is the sweet spot for BPM, round-tripping capabilities and sophisticated process governance are important skills. In the lower right quadrant, where BPM is used for IT agility, model-driven development and other technical skills are most important.
3. Those skills sets are not necessarily what you already have in house for other projects, although if you take a look around, you might find some of the required skills in unexpected places. For example, influential and collaborative people can be leveraged for transformational skills, while technical skills may be coming from the business community. There is a wide variety of skills and skill levels across each of transformational, operational and technical skills.
4. Transformational and operational capabilities are critically important; too many organizations focus purely on technical skills.

She showed an ideal BPM organization:

• A business process competency center (aka COE) reporting to an executive steering committee, and containing a business process champion, business process director, business process consultants, business process analysts and business process architects.
• An enterprise architecture program office, also reporting to the executive steering committee (not IT), working together with the BPCC.
• The process owner, who is responsible for improving business processes related to the corporate strategy.
• One or more BPM project teams, informed by the BPCC, and including an executive sponsor (linked to the process owner) and a BPM project manager.

The most critical roles are the process owner (a senior businessperson responsible for the end-to-end process performance), the business process director (business or IT background, but with a blend of all skill types, responsible for leading the BPCC and ensuring its adoption throughout the organization), the business process architect (business or IT background, a transformational role that liaises between EA and BPM, and establishes BPM governance and standards) and the business process analyst (business or IT background, responsible for modeling, designing and documenting processes).

She also defines a business process consultant as a senior person who can fill competency gaps in transformational, operational and technical skills; although I often work in the business process architect role for clients, this is probably a better description of what I do, as much as I dislike the word “consultant”.

She walked through five scenarios for how BPM is used in organizations, outlining some tips and pitfalls for each. For example, in the “visualize and rethink the process” scenario that fits into the category of using BPM for standardization and manageability, she mapped out the key skills required from each of the roles, such as process modeling for the BP analyst.

She finished up with some best practices for hiring and managing BPM resources, including:

• Overhire, since senior, experienced people can play multiple roles
• Establish decision guidelines so that it’s clear which types of changes need to be approved by whom
• Align to key business goals
• Leverage executive influence to get things done expediently

Overall, some good pointers for any organization implementing BPM.