Tagged...

I got tagged - Todd Biske got me. Which means I have to expose 5 things about me that are not commonly known (at least by the people that read this blog), then tag some other unsuspecting bloggers. So here goes:

1. I spent 12 months traveling in South America. I knew that I was reasonably proficient in the language when I could argue with taxi drivers that chose to drive the 'turista' the expensive route.
2. I used to play tenor sax. I was probably terrible but would love to have learnt how to play the instrument with some subtlety.
3. I think I must be the only person in Massachusetts that doesn't own a car.
4. I'm a pretty good skier. I'd love to be in Colorado right now up to my knees in snow. Unfortunately I'm writing this because I'm sitting in a ski house in the North East US watching the rain out of the window. Global warming makes me unhappy in so many ways.
   
5. I enjoy playing football (soccer) despite being pretty awful when the ball is at my feet, but I'm fast and have good stamina so I make a decent defender. I miss the intra-office games that we played when I first starting working, as there is nothing like running out some work frustrations by kicking at your boss's ankles in a competitive setting.
   

Sorry guys, its the holiday season, so I'm having a little fun - you're tagged: Bruce Silver (a great source of thought provoking BPMS discussion) and David Rudolph (my new found colleague blogger). Happy Holidays/Happy Christmas!

Technorati tags: tagged

Improving applications upsets users?

As many bloggers go quiet over the holiday season it gives me a good chance to catch up some reading on blogs I have missed over the last few weeks while working through the recent product release at Global 360.

A nice series of posts on Tyner Blain caught my eye: Going Agile, 10 Mistakes. Its interesting for me since unknowingly, the R&D groups I work with are so experienced and have so much background working together that agile techniques are implicit to much of what they do. They are ideally placed to head away from the 18 month major product release cycles they have been tied to in the past and towards a more incremental enhancement program.

The interesting challenge would be how customers react to products that can constantly deliver more benefits and features. On the web, product constantly update and expect their users to keep up. In the corporate world, users gain much of their effectiveness and efficiency from complete familiarity with the software applications they use.

I wonder if anyone has experience of this. Can the constantly improving world of the web translate to corporate applications? Do small incremental improvements help users adapt gradually to changes, or do they constantly unsettle and upset?

Technorati tags: Agile Development

Exposed as a blogger

And this is why any blogger should follow essential rule "would I cringe if my mother read it?": yesterday I had the pleasure of having this blog passed by email to a group of colleagues. I have been exposed as a blogger amongst my peers!

The whistle-blower? A blogging colleague, David Rudolph on Good Karma for Enterprise Software. And his is a nice blog too, talking about a range of enterprise software issues.

So, thanks David! Now I have to be less careful about making my mother cringe and more about a Global 360 salesman asking me whether our products have all the things I talk about in this blog. Of course, standard smallprint still applies: "None of the views expressed here represent those of my employer, they are mine alone.". In short, unless I state it directly, my colleagues should not infer the existence of anything in Global 360 products from my blog. That's why we have sales collateral, and very soon new website content that I'm writing between sips of coffee!

Technorati tags: blogging

Preparing to release

I haven't disappeared off the face of the planet... Blogging will resume once I have shepherded the upcoming major release of Global 360's Case Manager BPMS product through to GA.

Its an exciting product, and this release really sets it up to be a leading human-centric, content-enabled and service-oriented enterprise BPMS. I can take no credit for anything in this release of the product, beyond the occasional powerpoint presentation and some typical product management administration. So, to the amazingly experienced set of development and QA engineers here in Hew Hampshire - keep it up, and thanks!

Technorati tags: Product Release Global 360 BPMS

Process Analytics - separate is better

When it comes to sales scenarios, customers typically ask BPMS vendors for evidence of their built in process reporting and analytics capabilities. For many process deployments, having built in tools is desirable, since they typically come with canned reports that show the generic information a process manager could need. What I'm recognizing is that there is considerable value in having analytics tools that are completely separated from the BPM engine and able to provide information across a range of systems and processes.

My previous post included a discussion about why process analytics is more than just analyzing the process. Even in a BPMS that has a 'full-bodied' view of process data that includes descriptive business metadata, built in analytics tools will probably struggle to present more than just basic business and process information. This is partly because built in tools tend to work directly off of live data as standard SQL queries, and partly because they are still limited to the data within the system, however broadly defined that may be.

It seems that separating out the business process analytics tool from the BPMS has some advantages:

1. Analytics is complex - separate tools are more specialized and capable
2. Analytics should look at more than the process - separate tools are designed to access integrated BPMS and third-party information systems
3. Analytics is processor intensive - avoid overloading the production system
4. Analytics should be incorporating your SOA strategy - analytics can provide a more complete performance view if it can provide and use SOA based information
   

1, 2 and 3 are fairly obvious. Specialized business process analytics tools can provide analytical information broader, better, faster. I didn't include 'cheaper', as there is a cost attached, and this will be greater if a tool is selected that requires specific custom integration (or a lot of configuration) with the BPMS. Pre-integrated BPMS + analytics tools, although separate packages, will almost always be more manageable in the long-run than a custom integration.

So what about the SOA strategy? Here I will sidestep the SOA v. BPM debate about where they intersect. How ever you look at it, SOA presents several challenges and opportunities to process analytics. First, how do you make use of the data and process that overlaps from human BPM into the SOA orchestrated process, and second, how do you design an SOA that enables access to analytics tools?

The first point acknowledges that there is a large overlap between SOA and BPM. Imagine a human-centric business process that also consumes business services and orchestrates integrations - for example, a loan application process that receives electronic applications from a business partner, and coordinates a process involving human assessments, automated decisioning and updates of the main banking system of record and CRM system. Embedded BPMS analytics tools can easily provide a range of analytical information within the bounds of the human-interactive process. The problem is how to gain value from the systems interactions, in terms of:

• business data - for the business
• technical performance - for IT
• cost - for B2B interactions

Using a BPMS that can seamlessly orchestrate service invocation and integration alongside human-interaction will greatly assist in providing the appropriate information for process analytics, since much of the data will be made available in one place. If this is not the case, the analytics tool must be able to look inside service requests and integrated systems and be able to reconcile the information it finds. If the analytics tool is open and extensible then this will be an option.

In many cases it will make sense for the analytics to focus on purely systems-based business services in the SOA. An example is an online loan customer inquiry. In a call center environment, process analytics would typically focus on attributes like the time to answer, abandon rate, loan value, type of request, all divided by class of customer. In an online world, similar information should be provided to the business to assess the effectiveness of their website, marketing and backend application processing, but the website analytics may not be the place to most manageably gather it, especially since much of the required information would not be exposed at this level.

By tying process analytics into the system that orchestrates real-time request services, valuable analytical information can be extracted from business information. This again is made simple if the BPMS that handles the human-centric backend processes also orchestrates and publishes the services used by the website. Even if the human and systems orchestrations are handled in separate systems, using a process analytics tool that is not trapped inside either engine will simplify access to the required information.

I'm really starting to understand the value of having true process analytics existing outside the process systems, enabling it to look across any information it requires. In the converging BPM/SOA space this makes more and more sense to me, though I'm sure that as I start to dig into this further with real tools I'll find out that I need many refinements to my thinking.

Technorati tags: SOA BPM process analytics

Analyzing [what is in] the process

In my post yesterday Process analytics is more than a pretty graph, I talked about the use of Process Analytics tools to do more than just monitor workload, rate of processing and so on. This fitted into the Execute & Analyze phase of a business process optimization lifecycle. James Taylor commented that:

Process analytics is also more than analyzing the process!

In my post I implied this a little by touching on the importance of strong analysis tools to provide information against business KPI and objectives, rather than just the process metrics. Though as James says, there is far more to it than that.

For instance, if I can predict that an account is at risk of going into collections I can route it differently. This is improving my PROCESS with ANALYTICS but it is not about analyzing the process.

This is the transition into the next state in the lifecycle: Manage & Improve. For example, goal management could fit in here, driving the automated routing of many process items based on business KPIs. Now accompany this with business rules, and complex decision analysis at an individual level, as discussed by James in his post. Use the right tools and work can be automatically routed both in bulk and individually to meet the complex requirements of enforcement, processing, performance and business goals.

Much of the benefit of process analytics for more than looking at workload requires a fairly 'full-bodied' view of process. For analytics to work well, managing the business goals, enforcement, and so on, I don't believe process can just be viewed just as abstract work items bouncing around a workflow touching people and systems. Process analytics needs to work alongside a formal business process that manages fully laden process instances:

• Containing complete, descriptive business metadata
• Linking to entities in other systems and providing access to their data
• Managing and referencing content, documents, discussions and tasks
• Enforcing the delivery of work to appropriate people, systems and services
• Making available specific data that is required for your analysis and management aims
  

With tools that support this level of meaningful business process, implicitly 'analyzing the process' becomes 'analyzing what is in the process' - real work cases, customers and accounts. Having access to the valuable business information directly enables process analytics to positively drive the process based on this data. Sounds easy? I'm sure that there is a lot that I need to focus on in this area to get a full picture of how this actually works in practice!

Technorati tags: Financial Services Technology process analytics BPM

Process analytics is more than a pretty graph

One of the technology areas I've been enjoying getting my head around in my new role is Business Process Optimization as it relates to BPM. As I'm starting to understand it, the optimization of business processes can be represented as a lifecycle, stepping through three main phases:

1. Model & Simulate
2. Execute & Analyze
3. Manage & Improve
   

In the dim and distant past, long before I ever considered joining Global 360, and perhaps when my knowledge of the BPMS market was limited by the constraints of the products I worked with, I had a pretty good discussion about Model & Simulate. I'll probably return to this discussion in the future, since I think there is still some legs in the thinking around simulation where integration (or SOA) is involved.

As for Manage & Improve, in my past I naturally assumed that this was just a function of making sure that the process was well designed and roles flexibly assigned so that fluctuations in workload were well balanced across the available workforce. That is only half the story, but the need to Execute & Analyze effectively are still the foundation for effective processes.

In simple workflow environments a quick report and a simple graph can provide all that is necessary in terms of 'analytics'. It can show a manager at a glimpse where work is building up in a process. But in high volume, complex business process environments, that have constraints applied through contractual Quality of Service agreements or a need to provide exceptional customer service, the analytical capabilities of a system need to be a lot greater. Examples could be credit card dispute resolution, call center customer services, life insurance application processing, or brokerage account opening.

In these complex environments, managers need up-to-date data that can represent work sliced and diced across many dimensions. This enables them to see not only that there is a large mass of work collecting in one activity in the process, but whether that places their highest value clients or service contracts at risk. True process analytics tools can understand the structure and 'flow' of work in business processes, enabling them to produce OLAP cubes for complex analysis. And since it does this by capturing an event stream representing work being processed and routed, by taking the data offline there is not the huge processing impact on the live system that complex database queries would have.

Now that managers can see and respond to predefined analytics, as well as having the tools that enable them to simply visualize the data sliced according to their own local requirements, the job of analytics is done, right? Not really. Process analytics enables slices of data to visualized over time, enabling trends to be spotted or the impact of specific conditions (for example a spike in volume of high value work) to be assessed.

Being able to understand how a business process responds under real conditions seems like the ultimate proof of performance. In a crazy day, where everyone is working flat out, a manager may not be able work out from 'gut-feel' alone how well his process is responding to this big spike in demand. Given data and easy to drive analysis tools after the fact, he or she can quantitatively understand what was different to other days, what went well and where improvements could be made.

I'm really just a beginner in this business process optimization world, but I understand that business process execution can be run in several way: just get work through and out of my sight, or get work done that really benefits the business. With experience, Key Performance Indicators (KPI) can be developed that provide the manager with an 'at a glance' metrics showing if the process is running to plan. The aim of the business is not necessarily to hammer out 10,000 cases an hour, but really to beat the true goals of the business that his teams should be bonused on - be that profitability, customer satisfaction, value of new business, etc.

With a business process that has been optimized based on quantitative experience applied to real metrics, and with analytics that have been built to be meaningful in the heat of the moment, a manager can really work to exceed true business objectives.

Technorati tags: Business Process Optimization process analytics BPM objectives

Feature ticklist trap

A great post on Tyner Blain by Scott Sehlhorst comments on the Fifteen Ways to Shut Down (Windows Vista). This enormous set of ways to shut down a PC led Scott to talk about how software that has every feature under the sun to satisfy every requirement actually makes everyone unhappy. Quoting Joel on Software

Inevitably, you are going to think of a long list of intelligent, defensible reasons why each of these options is absolutely, positively essential. Don’t bother. I know. Each additional choice makes complete sense until you find yourself explaining to your uncle that he has to choose between 15 different ways to turn off a laptop.

As I work with a well established product that has many customers, in a company that prides itself on customer satisfaction, the desire to provide functionality for every customer requirement and request is a challenge. There is little option in this environment but to implement the functionality, so it is fortunate that the development team have a huge amount of experience and handle this balancing act with the appearance of ease.

Even for a skilled team like this, the holistic approach that Scott talks about can be valuable to help ensure excessive complexity is not introduced to the software. He highlights ways to handle structured requirements that focus on the interaction by personas (categories of users), rather than directly trying to satisfy each requirement in turn:

Multiple requirements can lead to multiple, locally-optimized solutions or features. A holistic view needs to be taken to assure that we aren’t introducing too much complexity with these variations of similar features. Interaction design gives us a big-picture perspective to make sure we aren’t making our software too hard for our target users to use.

This persona based design is valuable not just to make sense of a vast array of requirements, but in general so that business analysts and software developers can understand what it is they are proposing and developing, beyond the individual feature / functionality of the standalone application, business process or composite solution. A while back I attended a Pragmatic Marketing course on Requirements That Work that introduces this really well, and was a really enjoyable interactive classroom day. I'd recommend this to anyone that has to work with software requirements.

The advantage that many enterprise software applications have is that they are supported, configured and customized to meet the needs of their own user base. This enables IT departments to hide the unnecessary features and options from their users. Windows Vista, Office and Outlook don't have this luxury. They need to meet the requirements of a disparate, varied audience, with a range of skills and needs.

It seems that Vista needs to learn from the potential failings (and subsequent enlightment) of the Linux world - that if a user doesn't understand an option or function they will ignore it, maybe select the default, then avoid using the software in future. The Debian OS gives skilled users everything, complete with the associated complexity - Ubuntu, which dubs itself 'Linux for human beings' gives 80% of users the defaults they would have selected anyway, and hides the rest. Debian is not well adopted by average desktop users. Ubuntu seems to be doing better in that arena.

Microsoft needs Windows Vista to be a success, and it will only be that if seen by users as being a worthwhile step forward. But it needs to fight its way back out of the feature ticklist trap if it wants to ensure user adoption. I hope that there are not 15 ways to buy and upgrade the OS as well. If there are I may not ever get to the point of selecting one of 15 ways to shut it down.

Technorati tags: Vista requirements definition user adoption

SOA for viewable documents

As customers extend their SOA strategies more and more, a question seems to be arising - is SOA a good fit for documents (like PDFs, TIFFs, Word Docs) and other binary content? Of course SOA powered by an Enterprise Service Bus (ESB) or some other mechanism for composing services can handle binary data, its just a question whether it really makes sense to push all of this data through it.

My background is in document imaging. Imaging and high volume document management systems typically have built up extremely functional image and document viewing capabilities over the course of their often lengthy existences. These viewing capabilities were built with the following design criteria:

• Responsiveness - how fast can a user be presented the specific information they are requesting so they can continue working.
• Server performance - do not request more data from the server than is really required by the user to view the document. Don't send unnecessary resolution, color or pages, dependent on predefined user requirements.
  
• Network performance - in the days before even 100Mb networks were commonplace, managing network usage was important. In large scale, or distributed implementations it still is.
• Seamless presentation of multiple types - documents come in many different types, and it does not make sense for easy processing of them for the user to have to navigate different native applications, let alone deal with the load time for some of them.
  
• Onion-skin annotation and redaction - the ability to mark up any type of document you can view is essential in some environments, without damaging the original document.
  

Viewer technology was largely based on a thick-client paradigm to allow it to meet most of these requirements. Stellent (to be acquired by Oracle) offers a range of image viewer technology as its Outside In product line, which has been the backbone of many thick-client image viewer apps. Spicer offers a range of viewers, especially focusing on complex CAD formats. There are others as well, but their number is limited.

Even now, there are very few applications that can present thin-client views of documents and meet the previous design criteria. Daeja is one third-party Java applet that can be integrated to meet this type of requirement for image and PDF documents. Global 360 has powerful thin-client image viewing, annotation and capture to support its BPMS and Content products.

The thing with all of these options is that they have traditionally been designed to plug directly into their imaging repository, either through TCP-IP proprietary file transfers, or for the thin-client versions as standard HTTP GET requests. And that is just for the image viewing. The upload of annotations was specific to the application. This does not fit SOA well, where organizations take the approach to extremes and insist that the ESB sits between all end user applications and their servers, using pure SOAP web services.

Many of the advantages of the viewers is the smart ways they access their servers to get best performance. It seems like a poor use of resources to build an SOA layer between a viewer application and its related repository server, just to enforce a dogmatic approach to SOA. Unless it is really justifiable to be able to reuse any viewer technology (which as I say there is limited choice), or allow a single viewer to access any repository (a complex proposition to do well).

Even if ESBs can handle this type of binary files effectively and efficiently, I am struggling to see if this is really a pragmatic approach to SOA. There must be some value to doing this that I have missed, probably based on my outdated background in this area.

Technorati tags: SOA imaging document management ESB

Customer relationship management from Bankwatch

Colin on Bankwatch has written a nice summary of CRM and how it relates to banks: Customer relationship management | Wikipedia

As he says:

The vision for CRM is entirely relevant for Banks, but is way ahead of either capacity to afford, or certainly capacity to implement due to disparate systems.

As Colin talks about in Its not about transactions, its about relationships! CRM can provide better relationships between banks and customers, and this can lead to strong upsell of services over time.

This is the key point as I see it for CRM. For any vendor to be able to help customers feel comfortable across the many different interaction points they have, and the many different call center personnel they may speak to, the vendor needs to provide enough knowledge of the customer's profile for the interaction to go smoothly.

CRM can provide this, as well as ensuring that information across the many disparate systems that contain customer information are easily accessible, and present useful information to the vendor on demand.

Integration of systems is essential, and being able to make a good guess of what is needed from which system, in advance will make any call center worker's job easier. BPM, SOA and CRM together can be very valuable if the technology helps the vendor's user, and doesn't just add more complexity to their job.