Rules and Business Processes

It has been raining like crazy in Boston today, so I've had an excuse to sit and catch up on some blog reading that has been a little sidelined since I started my new job at Global 360.

So I was really pleased to run across Bruce Silver's analysis of Where Rules Engines and BPM meet. Business Rules Management Systems (BRMS) are something that I am getting more contact with now, and Bruce really summarizes them well:

In fact, the heart of a business rule management system is in the rule repository, which supports rule discovery, governance, versioning, traceability and reuse across the enterprise. The business rule engine executes business rules defined in a structured rule language supported by the BRMS rule design tool.

Corticon is the system that I have been looking at, with its integrations with the Global 360 enterprise BPMS products. Before moving seriously into this space I believed that most of the value of BRMS came from the rules engine and a user's ability to powerfully define rules in a fairly understandable manner. Now I'm starting to understand the potential of the modeling, central rules repository and rules 'lifecycle management'. This really allows customers to define their policies and rules for decision making and guiding processes in one place, enabling their reuse and consistent application across multiple processes.

BPMS can really benefit from the rules engine, and centralized rules repository during execution of processes. Pulling the remaining rules management seamlessly into place alongside process management is more of a challenge than just integrating the process and rules engines, but is essential to ensure that there is a seamless enterprise view of the way IT systems are managing the way the business runs. Pulling systems together for seamless modeling is always hard - especially when much of their value can also come from them working independently. This is something I need to spend more time concentrating on.

Technorati tags: BPMS BRMS

Consider policy over process

Its not often I will directly 'advertise' vendor specific events or information, but in this case I found that this webinar, pointed out by Sandy Kemsley on her Column 2 blog, was a great reinforcement of why I made a move to Global 360.

Stories that relate to large brand names like Nike doing things better using a company's technology are OK. When they also communicate best practices and lessons employed and lessons learned the story becomes valuable to a wider audience. In this case, as quoted by Sandy:

Their lessons learned:

• Consider policy first, then process, then people, then tools
• Get senior management buy-in
• "Eat the elephant one bite at a time" -- this is so key, and something that I've written about many times before: do something small as quickly as possible, then add functionality incrementally
• Rent experts -- how can I disagree with this? :)
• Leave the rocket scientists at home -- in other words, it's not as complicated as you think it is; keep it simple
• Build a team that you trust and have confidence in -- provide direction and support, listen to what they need, and stay out of their way

I agree with the points, despite having to think through the first one a few times before it really sunk in. After a moment though I realized the obviousness of it. This really is just a drill down from high level to low level consideration:

• Policy: defines the goals of the business and the top level constraints / approach for how to get there


• Process: starting at a high level and working deeper, this reflects how to model, track, manage, enforce and run your business to meet your policies


• People: now that the process is defined, the right people can be used to handle the tasks that are needed to run the process well. Modeling a process around the people and what they do now is 'paving the cowpath' and just automates bad processes that do not help acheive the business' policies.


• Tools: as ever the best technical decisions are made last - pick the technology and vendor because they help achieve your goals, not just because they carry the currently fashionable tags.

It all sounds obvious, but often organizations will miss that first stage of setting policies, goals, objectives etc and jump straight to 'process'. That gives no frame of reference, no view of what is 'success', and no view of how much to actually spend on solving the problem. With the right policies in place the next lesson learned, "senior management buy-in", has probably already happened.

Technorati tags: BPMS best practices Global 360

Next Generation BPMS - does it need CRM?

The Bankwatch blog has been churning out a lot of content that is really interesting to me at the moment, thanks to Colin (where do you get the time for all this stuff!?). Today's post, Forrester Research: CRM Market Size And Forecast, 2006 To 2010 uses the quoted research as an entree into a discussion on why CRM is unlikely to really improve customer satisfaction in call center, and presumably other customer facing environments:

Bottom line, today the text based notes stored within CRM systems are relatively useless. The time taken to read them during each interaction nullifies much or all of the benefit, depending on the speed reading capabilities of the agent/CSR. I am starting to see the next generation of thinking on this, and its going to be controversial, because of the enormous spend on CRM to date.

Colin's comments come along at the same time as I'm looking at the "Next Generation BPMS" - not BPM 2.0, which when described by Ismael Ghalimi has a central theme of standards based modeling, simulation, analytics and of course process execution. I'm thinking of an all-encompassing business suite that incorporates not just process and all of its supporting capabilities, but also content, integration, collaboration, security, identity, metadata repository and a host of supporting admin and configuration features. Should CRM be a component of a Next Gen BPMS?

James, writing Enterprise Decision Management (EDM) blog often touches on CRM for customer service. A recent post talks about the use of EDM or BPM for call routing in a call center. Both EDM and BPM can make use of customer data or profiles to help decide how to route a call most appropriately. In this environment, the customer data would probably be held in the CRM. It is only the customer data that is used for automated decisions, and many of the facets of CRM including the text-based history of customer interactions are not required. Maybe a relational database schema would have been sufficient to capture this data.

I have tried looking at BPM vendors that have addressed this question in the past. Pega obviously shapes its process offerings around its CRM background. As I understand it they have a strong (although not alway rapid to define) object model that represents the customer data, supported by a process engine. The analysis and definition that is performed is typically approached from this standpoint, rather than the process standpoint that would typically be attacked by other BPM vendors. Activities and display are driven from the data, so this is important, and makes customer data central to their focus.

Way back pre-TIBCO, Staffware acquired a CRM vendor. When I saw it (pre-Vignette, when Tower Technology was a leading Staffware partner in the UK), the CRM component was not really integrated with the workflow and it was hard to visualize how the two were going to work together effectively. Looking at TIBCO's website it is hard to see if the CRM technology exists in any of their offerings. Perhaps some of it was fully embedded into the iProcess engine. If that is the case, it is more of a relational data model that is important, not the full blow CRM capability.

At this stage in my Next Gen BPMS definition CRM is not a component. Instead I'm going with a BPMS that provides flexible case folders supported by definition and access to relational data, internal or external to the system. This BPMS allows me to represent any data I want to within a standard relational DB, or external system, using the data directly for process execution and displaying it seamlessly within a configurable user interface.

I'm open to offers on whether there is any more of CRM than a relational data model that I need. Anyone?

Technorati tags: BPMS next gen BPMS CRM relational data model

Integration alongside BPM - a comment

Colin who writes the great Bankwatch blog commented on my post yesterday about Integration alongside BPM:

RE: "Once processes or integration requirements become complex the initial integrations may become a larger effort"

Not being the technologist, but isn't that where web services, and middleware are supposed to layer the problem into manageable, similar processes.

Colin, I've read your stuff - you get technology better than most! Sorry for reusing your comment in a post, I just thought it was important to follow up for the masses (well I can dream!). Rereading my post I can see why Colin makes his comment. I seem to imply that there is no solution to the problem. So I'll try and clarify...

BPM, document management/archiving and collaboration are integral to most real-world business processes. Many BPM/ECM vendors provide each of these components standalone, and even for their own suites of software provide toolkit based approaches to integrating them. From my experience, the requirement for this routine, infrastructure based integration is what absorbs a lot of project time when it comes to implementation of business processes. That is why I would recommend using BPMS suites that seamlessly incorporate all parts. Full disclosure: I have worked for two vendors (including my current employer) that provide this and am still impressed by how fast real processes can be deployed when you don't have to do this basic integrations every time you deploy a system.

Colin is also right where he states middleware can help break the integration down and make it maintainable and more reliable. But to me, Web Services in my mind are an enabler of this. They don't simplify the application integration at a business level, just provide a standard mechanism for integration at each of the touchpoints. That is why I don't associate SOA directly with Web Services. SOA to me is what can really break down integration into manageable and maintainable chunks.

The best that most BPMS can do now is to talk to the SOA 'middleware', or 'enterprise service bus' (ESB), or maybe straight to the exposed Web Service endpoints provided by an SOA project. This final approach is fast, but feels again a little brittle when it comes to changes. But the middleware or ESB requires integration to the BPM process - another layer of integration is born.

I'd like to see this scenario improved, with BPMS and SOA working side by side without integration of yet more infrastructure pieces! Maybe its out there. I think that most of what is there is marketing fluff...

Technorati tags: SOA BPM ESB integration

Integration alongside BPM

Integration of third-party business applications and data into Business Process Management (BPM) applications is essential, since very few real world business processes run standalone. Users need to apply their knowledge to information in their line of business system, making decisions and entering data that is reflected in the process. Automated transfer of data between BPM and business systems aids automated processing.

Most BPM Suites offer some level of integration within their capabilities, usually being able to talk SQL to a database or maybe configure a call to a Web Service within a process activity. For UI integration of business applications to avoid swivel chair integration by users, while presenting a seamless user interface for best productivity and experience, developers are called in and API bonding commences.

For a few points of integration at a handful of points in a process this 'in-process" and "in-UI" integration is bearable and maintainable. Once processes or integration requirements become complex the initial integrations may become a larger effort than deploying the process, and maintenance becomes difficult since every change in any component on the system carries dozens of dependencies on the process, data models and hard-coded integrations of multiple other components.

With a pile of separate BPM, content, database and business components I don't know of any real way of avoiding this. If you know of great examples of disparate platforms that really do this well, let me know.

So in my view it makes most sense for IT teams to make things easy on themselves to start off with. Using vendor products that provide as many of the key process, collaboration and content features within a seamless product can avoid the most common and repeatable requirements for integration. Why do unnecessary integration?

Then make use of Web Services or messaging components like JMS and MQSeries messaging to decouple process from application wherever possible. Finally, ensure that the BPMS UI provides components that can be built into custom applications, JSP or portals, and work hard to develop a flexible integration, not a pile of brittle spaghetti code.

It is possible, and I've seen it done. It just takes a strong foundation and pragmatic steps. If you have great examples, case studies or supporting integration approaches, please let me know.

Technorati tags: BPM BPMS integration

How to web 2.0 your bank - use technology well

Colin at Bankwatch posted a great (and even he admits it, broad) discussion of How to web 2.0 your bank. At first I thought to myself that maybe this could be true for any organization with an online presence, but thinking again I believe that banks are one of the few categories that has really provided really pervasive online interaction with its customers. As much as it could be useful, I rarely interact online with other organizations that I have a long-term customer relationship with.

To really allow banks to run a successful online service, especially a web 2.0 one that provides more interactive, real time, self service applications, the infrastructure not only has to support access to appropriate backend systems, but needs to pull the bank's employees into the interaction in a manageable and auditable manner. SOA, BPM and Rules, often deployed in the backoffice need to be pulled closer to the main point of interaction with the customer. This would enable more automation of decisions, more sharing of customer information between employees in separate customer service centers when an issue can't be handled in one place, and more feedback to the customer for the status of processes that can't be completed immediately.

By using technology more effectively, the community interactions that organizations like banks are afraid of presenting in the web 2.0 world could actually be more valuable and less damaging than online groups complaining about poor customer service and unintelligable call center operators.

Technorati tags: banking web 2.0 BPM SOA Rules

Customer focused product management

As with any new job, the first few days are exciting as well as 'brain crunching'. I'm suffering the usual thing that everyone probably experiences, where I'm trying to get my head around a dozen new products and modules, a hundred new faces and names, and thousands of TLAs (three letter acronyms).

Fortunately I'm able to cope with the product side of things better than the first time I did this 8 years ago when joining Tower Technology. Back then imaging and workflow was a mystery to me, and even now I look back on that and wonder why on earth it took me so long to understand what it was about. I think that then I was introduced to the concepts from a pure technology background, so the actual reasoning behind the whole imaging and workflow space made little sense. This time around I have the 8 years of Tower and Vignette to help me get my head around the products faster.

I'll be product managing Global 360's G360 EX and G360 Case Managemer product lines, working closely with the other product managers, product marketing managers, engineering teams and so on. My first impressions are that the product engineering is really well run right now by the engineering directors, hopefully giving me some time to look at the more strategic side of role, while juggling the numerous customer related requests that are going to come through the door. Certainly, the customer piece is going to be especially important at Global 360, since the company is organized to provide a very high level and personal customer service. Quickly understanding, distilling and communicating all of the requests, issues and questions will be a key part of my role. Bring it on, these are exciting times!

Hopefully I'll be able to blog a little about some BPM and case management issues that strike me as important over the next few days and weeks. With hundreds of financial services customers, New Account Opening will likely get covered, but you can also expect governement, healthcare and industrial discussions as well.

Technorati tags: Global 360 Product Management

Reflecting on ECM

Russ Stalters at BetterECM was good enough to write me an email wishing me good luck in my new role at Global 360, as well as asking for some reflection on how ECM vendors like Vignette might survive the Microsoft Office Sharepoint Server (MOSS) 2007 opportunity/threat.

Here are the thoughts that I shared with Russ, and thought that with a little editing they were good enough to be make it as a blog. None of these thoughts represent an insider view of what Vignette is doing, instead they just represent what seems like good practice to me.

I truly believe that Vignette has some great technology. Unfortunately, like any independent software vendor that has acquired a lot of technology they probably have too many products in the portfolio to keep them all ahead of the game - the investment required to retain leading technology in every product through R&D is beyond what Wall Street wants to see from independent software companies. I would suggest that ECM vendors may need to rationalize what they offer by repositioning some products into a support role for the primary products (leaders) in the portfolio, thus not needing to compete directly with the competition on feature/functionality on every product.

Open Text may, for example, struggle keeping the multiple products offering the same capabilities alive for any length of time, let alone the second tier of unique products they have. Leading with every product into a vast set of sales opportunities does not seem smart to me. But having the huge range of capabilities in support products in the portfolio will allow deals to be won where a wide range of boxes have to be ticked.

Selling infrastructure is not going to work long term, although I think that an Enterprise play is still something that Microsoft will struggle with convincing CIOs of in the short term. I wrote a post a while back (in response to one of Russ's) that addressed this: ECM in a post Microsoft World. This was before the FileNet acquisition, and what I believe is IBM's play to capture the whole enterprise infrastructure market: IBM platform for massive systems reengineering

I think that smart independent ECM companies with large portfolios need to look at what they do best and focus on that. Too much time is often spend trying to chase every deal. The approach I would choose is to find a market segment where they have specific experience and expertise already, and can offer solutions that are a good fit for the business requirements. Hyland are still playing well, with a strong and effective focus on Healthcare and Stellent seems to be doing well in compliance and governance. The sales of these solutions probably makes them more money than trying to sell technology alone.

Finding ways of embedding ECM software into organizations where others have failed to penetrate is likely to be the next wave of ECM success. This will only be done (I think) if the vendors can find a way to make this happen, and I believe that a strong business requirements (as opposed to technology) focus is essential; in the past the technology sale has not got ECM much further than the website and focused operational installations when led by IT.

I'm looking forward to watching the ECM vendors as more of an outsider. My view is that BPM is core to really addressing business problems in many organizations and has great potential to become more pervasive. Content and BPM technologies are complementary, so I'm sure that I'm going to enjoy my future in Global 360.

Technorati tags: ECM solutions Sharepoint

Welcome to a new era

Things have been a little quiet for me on the blog scene as I've been trying to get myself together. I resigned my post at Vignette as a Solutions Architect last Wednesday. I had been part of the company since March 2004 when Vignette completed its acquisition of Tower Technology. I met some great people and worked on some interesting projects while I was there. As much as I was enjoying the challenge of working in the Industry Solutions group in the company, the innovation and excitement of the key solutions I had focused on had passed. It was time for a new challenge and my final day was Friday. The company has some great technology and talent and I wish everyone luck in the future.

Fortunately, I have been talking about an opportunity with a company outside Vignette since early July. After a long haul with visa applications, and a huge amount of patience demonstrated by the company (especially Ben Cody and Steve McDonald), I will be starting as Director of Product Management for Global 360 on Wednesday. I'm extremely excited to get myself fully embedded in pureplay BPM (something Vignette was lacking) while being able to leverage my experience in ECM and case management.

This is going to be an great new challenge for me, and so far Global 360 has lived up to their reputation and desire to be a great company to work for even before I get going. I know that they have seen a lot of change over the last few years and so I'm looking forward to driving further change and growth.

Technorati tags: career Global 360

Microsoft and EMC - Documentum is just an archiving hub?

By now, most people interested in the ECM space have seen the press release that EMC Documentum and Microsoft announced an alliance. Guy Creese on Pattern Finder suggests the EMC (like other vendors) is getting out of the way of the Sharepoint train:

Given the viral adoption of SharePoint 2003, and the new architecture of SharePoint 2007, the major ECM vendors are realizing that they can no longer dismiss Microsoft as a company that just generates documents.

As OpenText, Vignette and EMC Documentum look at Sharepoint 2007 and how it is effectively bundled with Office 2007, they have all probably realized that they need to evolve to either embrace Microsoft or find a new way to package their products. The huge marketing budgets that MS is bringing to their ECM offering is an alure, as well as a threat I'm sure.

Russ Stalters on BetterECM suggests that EMC Documentum should extend to the integration to workflow enable Sharepoint documents, which sounds reasonable given the need for strong workflow/BPM to support Sharepoint, although this may be a little shortsighted as MS enhances its document workflow capabilities. Though it obviously plays to Documentum strengths in its raw form.

I'm not surprised that EMC have stepped in here, but I don't believe that they are really trying to sell more Documentum software on its own merits. Documentum provides a single point of integration to hook directly in to a bunch of heavyweight storage boxes, which is probably the reason EMC is most interested in the partnership. Basically, Documentum becomes little more than a 'hub' for mediating storage to a range of EMC devices. But then as the press release states:

As part of this strategic alliance, EMC will introduce a set of new content and archiving products that enable tighter integration between the industry-leading EMC Documentum ECM platform and Microsoft solutions and platform technologies.

"Archiving" is a typical word used when the value of the content is minimal, a company is just looking to store huge amounts of it. If this is how EMC really sees Documentum + Microsoft, this is a perfect play for them in their role of tin merchant.

Technorati tags: Microsoft EMC Sharepoint ECM archiving

Adoption v Selection of BPMS

My little series of posts last week on document classification and tagging seemed to get away with a lot of other relevant blogging I could have been doing. As ever, some of the most interesting blogs I read were not really that time sensitive, but instead did a good job of revealing an individual blogger's experience at that moment in time.

The Workflow Blog talked about one of these experiences in "the look of workflow":

The interesting thing about this project was not the hours spent creating working workflow applications, but the weeks making things look pretty. Or in some cases not that pretty but to customer specifications. As a techie I am still struck by how most users would much rather have something semi-functional that looks pretty as opposed to something that actually works. I think in the end adopting a workflow system is not a rational decision based on return on investment but rather still an emotional decision.

When I first read this I thought that the comment on ROI surely couldn't be right. After all, every vendor gets pushed for the ROI they can offer, to help the internal project team further justify a hugely expensive IT project.

Thinking more deeply, it seems that the ROI between one deployed and running BPMS and another surely can not be that different? The thing is that much of the cost of a BPM project comes from analysis, design, and deployment upfront then a bunch of similar running costs. TCO of mature systems can't be so different to make a huge dent in an ROI to assist in making a justifyable decision, so emotional decisions start to play.

Re-reading the blog quote above, neither the adoption nor the selection of a BPMS is actually based on ROI. It is users that adopt systems, choosing through their own cooperation to work with a new system and work around its minor issues, or to choose to be inflexible and make the project and adoption of the system fail. As the Workflow Blog goes on to suggest, it is the emotional piece that vendors typically influence through "prettiness", and this affects both adoption and selection:

However as more and more companies start competing head to head it will not be the feature set that customers will look at in making decisions. It will not be support. It will just be, is it pretty to look at and easy to use. I am not sure any analysis by Garter et al really comes close to capturing this information.

Adoption is an essential thing to bear in mind when selecting a system. Every BPMS client application can be made pretty and functional though, so beware of being influenced purely by skin deep beauty. The real ROI that will make a BPMS a success can only be judged by how it can affect the bottom line and how quickly. The differentiation between systems comes from the day to day improvements to an organization's operations, how adaptable the system is to changing processes, and even more importantly can it react and optimize the processes under different circumstances like sudden shock loads and extended excessive demand. If you can manage user adoption by meeting the usability requirements, the deeper capabilities are what provide true business improvement.

Technorati tags: BPMS user experience adoption

Business process mashup - effective but maybe brittle

On the IT|Redux blog, Ismael blogs about Enabling Complex Workflows with Office 2.0. Here he presents his experience of connecting a series of standalone online applications, to provide a useful end to end business process.

The aim of Ismael's process was to automate the "lead to cash" process for conference sponsorships through the use of purely online services. As Ismael says himself, this isn't the most complex workflow he has seen, but has enough complexity to make it a useful illustration of what may people would just try and do manually because of the effort of trying to set it up with a traditional BPMS.

I'm impressed with what Ismael has working. For this level of complexity what he has done is probably more effective and appropriate than modeling and enforcing the process in Excel as would be done by most organizations. At the same time, by plugging components together end to end without a central point of orchestration or tracking makes the implementation feels brittle. This is not a reflection of the individual tools, more that I prefer to see automated business processes being coordinated from a central point. In any mashup where loosely coupled components pass messages from one to the next, if one component breaks or fails to pass on a message successfully to the next component, the process will not be completed, is unlikely to be recoverable and this will not be noticed unless a human goes back to check everything end to end.

I strongly believe in the importance of approaches that enable non-business users to implement business processes, and with the added complexity of integrating multiple components this is a challenge. Selecting the right tool for the job is important. In this case I might have chosen a system that incorporated more of the components that Ismael needed in a single package, to reduce the need for mashing up so much stuff. By using a system that already had seamless Forms, Process Management and Email, you could produce a less brittle system, hopefully with less effort. There are no Office 2.0 tools out there to do this at the moment, but there are vendors that offer Case Management tools, targeted at rapidly implementing just this type of business process.

It sounds like Ismael put this together partly to prove a point, and in doing so he has demonstrated that online Office 2.0 tools offer a decent approach to automating processes that others would have just run in Excel. That is a great step forward!

Technorati tags: BPMS office 2.0 Case Management mashup