I saw this article by David Kelly today, "The 'Longer View' on SOA Reuse" in which he discusses the need for various collaboration technologies and approaches in effective SOA. A couple of his comments made me think of how business rules and how they can play a role in SOA and in delivering re-use in an SOA. The first comment that caught my eye was when David said:

It’s also about creating, fostering and enabling a more collaborative development process and collaborative technology environment than most organizations are used to

He is absolutely right about this and it is one of the reasons I think business rules have so much to offer SOA. The ability to collaborate or do what Forrester calls Concurrent Business Engineering with Business Rules makes for a collaborative environment even down to the business logic in the services themselves and so resolve some of the issues of different perspectives. He goes on to say:

but the work actually starts once that service is successful

Indeed. This is what some writers have called "change time" and realistically it represents the vast majority of the lifetime of a service. While David lays out a number of steps to cope with this period, I think you also need to get set for change time by using business rules and that this can really help with services that are constantly changing. He also goes on to say that

developers, testers, operations personal and potentially even partners or customers gain a broader understanding of how services are defined, where they should be used, and how they’re supported.

and this means that the business and IT need to collaborate and learn to love, not hate, change.

Happy Halloween.

Technorati Tags: BRE, BRMS, business agility, business rule, business rules, Forrester, service, SOA

Posted by jtaylor in Business Agility • Business Rules • Decision Technologies • SOA | Permalink | Comments (0) | TrackBacks (0)

Technorati Tags: BRE, BRMS, business rule, business rules, service, SOA

Posted by jtaylor in Business Rules • SOA | Permalink | Comments (0) | TrackBacks (0)

I saw this article on dashboards - Dashboards Help Align Operations with Business Goals - by Raul Gonzalez today and it made me think about the value of a dashboard to front-end, operational staff. Raul says in the article:

"The concept of the dashboard is taken from the car dashboard, which provides critical information about the operations of the car, allowing the driver to make the right decisions related to driving the car, such as to accelerate or decelerate, or to stop for gas."

This is the classic example used to explain the purpose of the dashboard. When I think back to my early cars, the decisions I took about driving the car included things like manually controlling the choke. Today cars automate many of these decisions based on rules developed by experts and models that turn data coming from various monitors into predictions. The dashboard no longer includes the information relevant to the choke.

When we think about operational decisions, we should think about a modern car, or perhaps even a future car, rather than a past one. Instead of telling people about a problem, we should do something about it and report how well we did. Instead of tracking things, we should use this information to improve things. We must consider if the right thing to do is to automate a decision, not just report information to allow someone to make that decisions. This is the essential approach in decision management - automate and improve over time the operational decisions that drive the business so that business people can control the strategy not have to deal with the details of each transaction. Raul uses a good example:

"For example, one possible KPI for a customer service call center may be the average time a customer waits for his or her call to be answered by a representative. The desired goal may be a customer wait time of less than 60 seconds. The current average wait time compared with the goal can be shown on a dial with values between 0 and 120 seconds. Values above the goal of 60 are coded in red, values between 45 and 60 are coded in yellow, and values between 0 and 45 are coded in green. The color-coded background provides users with an immediate picture of the Customer Service performance relative to the specified goal. A second indicator in a customer service dashboard may show the directional trend of customer wait time - whether it is increasing, or decreasing. "

Now I would see this problem differently, when it comes to operational decisions. I can use the information to predict the likely wait time for new callers and then use rules to perhaps change the message or IVR structure, rout calls to different desks if some are busier than others, display a "hurry up" prompt for those on calls taking a long time, turn off the cross-sell/up-sell script for reps or otherwise deal with the problem. Now the operational staff don't need to see a dashboard as their environment adapts. The managers still need a dashboard but they can control strategy, not the details or each decision, using it.

Dashboards are good for managers. Decision automation is often better for operations.

Technorati Tags: analytics, business agility, business intelligence, business rules, decision automation, operational BI, dashboard

Posted by jtaylor in Business Agility • Business Intelligence • Decision Technologies | Permalink | Comments (1) | TrackBacks (0)

I just realized that I never posted a summary of my recent trip to Gartner's Symposium and ITxpo. I blogged a few times and presented so here are the links in case you are interested:

• AD Overview: Assembling, Buying and Constructing—The ABCs of Delivering Software Solutions
• Thoughts on the keynote (second hand)
• Business Intelligence, Business Process Management and Information Management Market Directions
• Enterprise Risk Management: The Benefits of Risk
• The New Business Architecture: Enterprise Architecture and BPM
• Real-World Experience in Applying Business Intelligence to Business Processes
• Driving the Customer-Centric Enterprise
• Analytics: Action Based on Integrating Processes and Applications
• Java and .NET: You can't pick a favorite child
• Impressions from the expo
• BPM Technology Selection: How Solutions Are Evolving

Technorati Tags: .NET, agile, analytics, BI, BPM, BPMS, BPO, BRE, BRMS, business agility, business intelligence, business process management, business rule, business rules, CRM, customer experience, decision automation, EDM, Enterprise Decision Management, Gartner, predictive analytics

Posted by jtaylor in Business Agility • Business Intelligence • Business Process Management • Business Rules • Decision Technologies • SOA | Permalink | Comments (0) | TrackBacks (0)

My old colleague John Parkinson had a nice column over on CIO Insights today - "How to Manage Application Enhancements". There's some good general purpose advice about how to manage application enhancement but on the second page John touches on some areas where decision technologies, especially business rules, can really help. John says:

"First, recognize that a lot of these requests are for things that users could do for themselves if they had the right tools, a little training and support and a "clean" information environment. Changes to reports, even changes to web pages and transaction screens can often be handled by the requestor, if the information management environment is robust, the platform architecture is solid and the right tools are deployed."

Absolutely right. When it comes to applications business users don't want to wait in a long queue for their day to day changes in particular. One of the right tools for this is the use of a business rules management system to manage application logic. The use of a business rules approach makes the logic more accessible to the business users and allows them to change it independently of the rest of the application for many kinds of changes. Examples include changes to marketing program logic, retention offers, pricing, bundling etc. Be warned, however, that business users don't want to change code, they want to change their business so IT will as John says need to make some invests in a suitable platform.

"IT departments don't seem to want to take this route very often (at least I have seen a great deal of resistance to it) because the necessary cleanup efforts almost always require medium or large changes to be made, and there's no budget for such efforts (or willingness to admit that they are needed)."

My experience also. However, many customers find that the investment in a business rules platform pays for itself very quickly - a bank in the UK for instance felt it recouped its investment in just 6 months through savings in maintenance costs and improved decisions while the DMV here in California reckoned to save 13,000 hours of maintenance work a year(I presented on this at a recent conference too). Getting IT to buy into this approach can be hard but mostly, once they see how many of the annoying updates are being done by the users and how much more time they have to focus on meaty projects, they come to like it. As John says:

"But the productivity gain from an effective self-service strategy is significant, and the improvement in customer satisfaction equally worthwhile. In addition, doing some things themselves soon teaches users to assess the real value of everything they ask for."

So if you have a business users don't want to change code how do you tell where to apply business rules. Well John has this to say:

"Secondly, many small changes cluster around specific sections of application code, so an investment in improving these code sections to aid understanding pays big dividends. Application understanding is the largest single engineering task associated with making a small change to an installed application. Over time, the engineering effort can be reduced by up to half."

And I would agree. This is the kind of application logic that can be effectively replaced by a business rules approach to net a great return. Rather than just understanding and cleaning up this code, you can replace it with a decision engine that can be maintained by the business. In an era where agility matters more and more, this could be the difference between growth and failure.

Enjoy.

Technorati Tags: agile, BRE, BRMS, business agility, business rule, business rules, legacy modernization, ROI

Posted by jtaylor in Business Agility • Business Rules • Decision Technologies • Legacy Modernization | Permalink | Comments (0) | TrackBacks (1)

I was reading a piece called "Creating an SOA-Enabled BPO Platform" by William Martorelli of Forrester this weekend and much as I liked the piece, he seemed to me to be missing a key component for an SOA-platform for Business Process Outsourcing - decision automation. He says

Faced with these challenges — and forced to achieve one-to-many customer leverage in order to make money — BPO (business process outsourcing) providers are adopting layered service delivery architecture capable of isolating them from complexity.

I completely agree that a decent software infrastructure, and one based on SOA, is going to be critical for BPOs in the future. However, while William's discussion of business rules, and the need for a business rules engine external to the applications executing the process steps that can be rapidly updated, is spot on I think he misses a couple of key points:

• The rules must be exposed in a way that allows the customer of the BPO provider to manage the rules.
  The critical capability is that the customer can continue to control the rules, even while the BPO runs the process
• The rules must be layered
  While some of the rules will be provided by the BPO as part of its expertise and thus standard across multiple customers, those being edited by a customer must be different for each customer. To build a scalable platform this means one service taking a decision but taking a decision in a customer-specific way. Some rules engines support this approach, others do not. If you have to build a rules-based decision service for each customer, it is not going to work.
• Many decisions involve both business rules and analytics - knowledge/expertise embodied in the rules and data analysis embodied in the analytics.
  Only focusing on the value of analytics in terms of process analytics is not enough. The BPO will need to allow customers to build models from data and inject these analytics into the decisions also. Smart BPOs may realize that anonymized aggregated data gives them the power to build analytic models also and use these to differentiate the service they offer, especially to customers that do not have enough data of their own.

William also talks about an SOA-based approach enabling multi-vendor BPO solutions. Here I agree with him and think we will see a growth in what Fair Isaac has started to call "Decision Service Providers" who provide automated decisions for use in other processes. Clearly a company suitable for efficient management of a process may not be the one suitable for making a complex decision involving risk-tradeoffs and complex analytics or one that is heavily regulated. Using a Decision Service Provider for this would allow the injection of critical expertise (in marketing, underwriting, retention) into an outsourced process, or indeed one being executed by the company itself.

I have blogged about the value of business rules in a BPO architecture before on my other blog and written about the value of business rules in implementing a digital business architecture such as Forrester describes as well as on how business rules can enable business/IT collaboration or "concurrent business engineering.

Technorati Tags: analytics, BPO, BRE, BRMS, business agility, business rules, Forrester, outsourcing

Posted by jtaylor in Business Process Outsourcing • Business Rules • Decision Technologies • SOA | Permalink | Comments (0) | TrackBacks (0)

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go. Last one was Derek Miers on "Achieving Enterprise Agility". Derek started out by pointing out that many definitions of process are based on manufacturing - orchestration - and not enough on collaboration - choreography - important as knowledge workers tend to need choreography not orchestration.

BPM is primarily a business philosophy, not about technology. How do people work on their processes and meet their objectives. Clearly there is technology that supports this but the business approach is key. Lots of reasons for doing this including customer-centricity, compliance, innovation, IT reuse, agility, risk management and so on.

Multiple interpretations of process - purpose of an organization (that orchestrates functions through practices) or a set of procedures lumped together. Implementation normally mixes practices and procedures. Processes might be one or the other or a mixture. Clearly those that focus on procedures, which tend to be more established and higher-volume, are where decisioning comes in. They tend to focus on repeatability and speed and be back-office focused. Practices tend to be more knowledge-centric and flexible and suitable for processes being done by knowledge workers.

People often show a 75-80% production, 15-18% collaboration, 2-4% ad-hoc and 1-2% exceptions. Even very repeatable, high volume processes still have some collaborative exceptions. Contract negotiations might be completely ad-hoc. He made the valid point that even if much of your process is production then much of your cost could be in the ad-hoc, collaborative stuff.

• Think Big - have an overall plan and have a decent project methodology
• Start Small - try something that can be completed in 60-90 days tops
• Iterate - keep getting better

Derek also encouraged folks not to over model or put too much in a repository before implementing - his preferred approach is to build some high level models from various perspectives and then implement and iterate. He also discouraged too much focus on input/output modeling as this can perpetuate processes to manage the information flow where a more radical approach might be to solve the business problem with less or different data. Lastly he suggested that folks "start again" when they being to iterate, using the initial models to help with understanding rather than trying to build on them.

Derek went on to discuss the Business Process Maturity Model and how it might be applied by organizations to help understand what kind of solution/approach is appropriate. This approach, based on the CMM levels, is described over on the Teraquest website. Derek clearly feels this is a useful approach while I remain cynical - I think we need to see more mature process-centric organizations before we can really establish a model for them. Interesting stuff though and the authors have clearly done lots of high-quality work on it so check it out.

There was one point he made with which I am going to disagree - he said that when things go wrong companies differentiate themselves. While this is true, one would hope it is a minority of instances that go wrong. Thus if they go right most of the time then it is how they go right that differentiates companies. Amazon is not differentiated by how it handles problems but by how reliable its core process is.

Technorati Tags: BPM, BPMS, business agility, business process management

Posted by jtaylor in Business Agility • Business Process Management • Business Rules | Permalink | Comments (0) | TrackBacks (0)

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go. Next up was Sarah Bloomer on "User Centered Design for Process Redesign". Sarah started off pointing out that system design is process design and that when designing a system or a process you're designing your business. She reminded us that user-centric design is not about focus groups or asking them to design the UI but engaging them in driving the design process because users are not software designers so can't design for you, only with you.

Users have knowledge, goals, job needs, context of use and, in addition, there are company goals and corporate culture that might be in conflict. User centered design involves "Observe and Analyze", "Design and Iterate", Evaluate and Refine", repeat. This must be done in collaboration with users. In particular the context of use - how and where people use it - will be key and is often the hardest to bring in. Contextual studies are about seeing how people perform their tasks in the real-world. This kind of information complements the formal requirements and fills in the gaps missed by other techniques such as their workarounds and job aids.

Sarah made some great points in her discussion of user-centered design:

• She pointed out that one should remember that the end customer has objectives as well as the person using the software e.g. in call center the customer gets an experience too.
• Her process involved doing both current and "blue sky" workflow analysis and then come up with a composite "realistic" to-be process and I thought that was a nice idea.
• Like me she likes personas - check out Alan Coopers site for more on personas - and had a good suggestion about wrapping stories/scenarios around a persona - check out this blog about story-telling in this context too.
• The kind of environment (noisy, busy, peaceful, home office) and tasks being performed make a big difference.
• User-centered design must consider the actual work environment as part of the process as where people work matters - what notes do they have on the wall? To what do they refer constantly and so on.
• Paper-prototypes can be more accessible for users than software, even prototype code
• Try and include direct users and those who benefit for the execution of the process to make sure they will get their benefit out of the new process

One more session...

Posted by jtaylor in Business Process Management | Permalink | Comments (0) | TrackBacks (0)

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go. Next up was yours-truly on "Driving Business Agility with Decision Services". I won't comment as I was, as usual, brilliant. Attached the slides I used for you to enjoy. If you want to know more about the California DMV, about whom I presented, you can check out my other blog for this article on DMV.

Powerpoint to download BPIS2006.ppt or use Slideshare:

Technorati Tags: business agility, business rule, business rules, decision automation, EDM, EDM, Enterprise Decision Management, legacy modernization, government

Posted by jtaylor in Business Agility • Business Rules • Decision Technologies • Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go. Next up was David Eckoff on "Innovation at the intersection of media and technology". This was a fairly humorous session for various reasons, not least that it was the end of the day and so everyone was a little punchy.

Media industry used to have very limited choices in terms of TV channels, movies only at movie theaters etc. Very homogeneous but not any more. Now many more kinds of channels, time-shifting with TIVO-like devices, place-shifting with Slingbox and so on. Fragmentation and choice are king and disruptive innovation is now a way of life in the media industry. Consumers are now creating content too - at concerts for example, people post photos, commentary etc. Lots of new deals and gadgets make for constant churn. Turner, David's employer, is trying to innovate in this environment. For example the new site, veryfunnyads.com, a place to see funny ads and email it around to people. Very consumer-driven, very viral. He showed a couple and some were very funny (like the March of the Penguins one from France). They make money from advertising around the advertising :-). Similarly a PPV service for minority sports PlayOn used by the Atlantic Conference for college sports. Key innovation by Turner was to provide a production kit (based on CNN field crews) for producing these TV shows cheaply and easily. Each school has one, they have interns working this! Completely handed over to rights holder so they can produce it themselves.

10 lessons learned about innovation at Turner:

• Innovate when you have a healthy core - as have money, opportunity for focus etc.
• Perfection is the enemy of innovation - good enough where it has to be, better where it can be
• Traditional metrics aren't helpful for analysis of markets that don't yet exist - very true!
• Innovation is a process
• Different resources and approaches for defending the castle vs exploring new territory
• Be seen as an ally - relationships matter
• Get some early wins
• Rome wasn't built in a day
• If you want to beat Bobby Fisher, don't play chess! - don't tackle big enemies in their area of strength
• Survival of the most adaptable

There was a lot of discussion about blogging so "hello" to everyone from the session! David's blog is www.davideckoff.com. That's it for today, I am speaking tomorrow.

Technorati Tags: innovation

Posted by jtaylor in Innovation | Permalink | Comments (0) | TrackBacks (0)

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go. Next up is Thomas Koulopoulos on Smartsourcing: A Method-based Framework for Making Sourcing Decision Thomas was introducing his Smartsourcing framework. He made some nice introductory comments:

• 10% savings from wage arbitrage and this is one time saving
• Rest comes from process improvement and execution excellence
• Very hard to outsource processes we don't understand but this is often the main objective
• Most organizations cannot allocate costs like IT to processes
• Ownership no longer denotes control - no need to own the whole chain any more
• Mostly about risk transference so accurate risk assessment is key
• One of the side-effects of outsourcing is documentation of the process!

Thomas then outlined a classic graph showing how rate of change and core v non-core gives candidates for outsourcing but reality can be more complex as I am still on the hook to my shareholders and regulators so perhaps have to keep some control. For instance, if a really good customer calls and the call center is outsourced, how do I make sure the cross-sell happens? I could route to the onshore person who is better or I could automate the decision.

Thomas's Smartsourcing methodology has a core level (a dashboard and some analysis - subjective and quick) and an optional level (starts getting into gap analysis, innovation assessment and benchmarking). Key concept is a two by two matrix with axes of "How good is your performance" and "How core is this is"

• Functional Processes are Core and Excellent execution- optimize and continuously improve
• Re-engineering candidates are Core but Poor execution - need to do better
• Outsourcing candidates are Non-Core and Poor execution (because you won't know a good version)
• Offshoring is good when Excellent execution but Non-Core as you could describe it to someone else to do more cheaply

This all changes all the time - time is a fifth dimension to this view.

Tom's assessment comes in a subjective approach (Level 1), more objective (Level 2) or scenario based Level 3). At each level the staff plot each process in the excellence v core chart as a bubble where size of bubble reflects uncertainty - a small bubble shows agreement in terms of mapping where a large one shows uncertainty of ideal outcome. Each bubble might be within just one of the four quadrants or might straddle several. Assumptions can then be analyzed to see who the processes move around the graph. Very effective discussion tool as it makes people think about processes and how they might be managed.

This seems like it would complement the work around decision yield, though I have to think about it some to explain how. Thomas wrote a book on this that I have not read yet but seems like it would be good - you can buy it and check it out here.

BTW I am speaking tomorrow.

Technorati Tags: BPM, business process management, outsourcing, BPO

Posted by jtaylor in Business Process Management • Business Process Outsourcing • Innovation | Permalink | Comments (0) | TrackBacks (0)

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go.

Christian de Neef was next up on When Your Business Knowledge Goes East... Key Risks and Benefits of Offshoring Business Critical Applications. Christian gave an overview of various markets for outsourcing and showed how large top-tier companies are moving more and more jobs offshore. One interesting note is that he and several audience members felt that approximately 1.5 jobs are created for each job outsourced thanks to the process style, asynchronous communication etc. That said, many of the companies in India, for example, have strong process maturity around Six Sigma, ISO 9000, CMM etc. Very disciplined on process but this can produce well managed rubbish if you don't watch it. He outlined how outsourcing started with infrastructure then application development now increasingly vertical. Knowledge Processes beginning to be outsourced also. I am not sure I buy this - I think companies are automating these kind of processes rather than outsourcing them (see this section on Business Process Outsourcing (BPO) on my other blog for instance).

His case study was on Axa and their attempt to reinvent themselves by using very fined grained segmentation, targeting with new product packaging and loyalty management (typical insurance strategy - see this section over on the other blog about insurance). They wanted to use a product factory (software to build insurance products), tariff engine (rating engine) and rules engine. But getting the rules right by analyzing code was hard and was outsourced. In this situation the outsourcer said yes too much (underestimated complexity, not enough Axa resources, quality of rules poor). The lesson learned was not to leave the rules in the hands of the outsourcer - well duh! That would be why you should put it in a rules engine! Then your business people can control them and the outsourcer can run the process.

This was more of a case study in how NOT to manage legacy modernization and all these problems are typical when folks try to get legacy rules into a rules engine without thinking about it enough.

Christian was an excellent presenter and I am not saying that just because he gave out Belgium Chocolates! I am speaking tomorrow.

Technorati Tags: agility, BRE, BRMS, Business Rules, decision technology, legacy modernization, BPO

Posted by jtaylor in Business Process Outsourcing • Business Rules • Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go.

Marc Kerremans was my next session on Continuously Bridging the Gap Between Business and IT. Marc started with a discussion of how his company closed the gap between IT and the business in a client. The starting situation was that there was ISO work driven by the quality group while IT doing local workflow-centric, technology-driven projects with lots of consultants. IT called this "BPM" and built systems that were not used. The restart was driven by his failure - they wanted to regain credibility for BPM by aligning solutions with IT infrastructure. The restart involved a very short project with narrow scope that would also generate a BPM reference architecture. First step was to prioritize projects based on things like skills in house, can you standardize a process, does it fit? Procurement came up as a candidate. They kept the analysis high level (purchasing dossier) so as to keep scope limited and only focused on steps that changed status of dossier. Avoided integration and electronic signatures. Brought process/business people and technology people together to develop solution/implementation and made sure that the functional analysis showed manual and technology steps in a single flow. Next step was to drill-down into more detail and remove the constraints around integration - this was about 3-4 months. Changed the system to reflect a to-be process and tried to focus on integration of this initial project into full context. Increasingly the client led this analysis and were able to make further progress.

Learnings from the project:

• Try and abstract a more general problem/solution before building a specific one for a specific problem
• Focus on business operations not on the flow of a specific object flowing through a process. This means modeling transitions between activities and interactions between participants
• Find the "push/pull" point between top-down BPM drivers and bottom-up technology drivers
• Various kinds of processes - flow(sequential), connected (one connects to the next), disconnected (gaps), jumbled (all mixed up) - and need to understand the kind of process to model and manage them correctly. You can manage at a higher level for coherent processes (and must do so at a lower level for more jumbled ones)
• Need to consider content / data as well as process flow
• Phased approach with quick hits
• Question official procedures as may not be what really happens
• Align process and IT architectures

All good stuff. I think the role of decisioning in these different kinds of processes may well be different in each case but any time you want to eliminate manual steps you should consider it. I am speaking tomorrow and Marc also talked about BPM Forum in Europe at www.bpm-forum.org that might be worth you checking out.

Posted by jtaylor in Business Process Management | Permalink | Comments (0) | TrackBacks (0)

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go.

Next up James Heideman on Using Process Improvement Tools to Drive Organizational Culture Change. James spoke about adopting a "Six Sigma"-like process at Nissan. "Nothing endures but change" - at Nissan culture change was key and much harder and more of a challenge than expected. Change is certain and yet hard to cope with - triggers "corporate immune system". The same tools for issue resolution can be effective to improve the change process itself. James felt the program at Nissan succeeded because of 6 elements

• Integrate
• Improvement process is part of the organization - don't separate out from rest of corporation.
• Made process leaders part-time, kept some organizational responsibilities and then assigned them issues relevant to their day-to-day job and that worked better.
• Key to success was reporting early wins and the impact of them.
• Avoid the bureaucracy and build a steering committee that is broad and deep so can break logjams.
• Embrace believers, convert others
• Did regular stakeholder analysis regularly - measure their interest, assess impact etc.
• Act
• Focus on essential training - don't use 2-3 months of full time training for everything but train on essentials and then develop more skills as they improve.
• Get to work on real issues that hold back the organization not on the process improvement process itself
• Used a Six-Sigma chart (Pareto Chart) to assess tools being used in improvement projects and focused on training those tools, not less-used ones. Found that many of the soft-skills, group interaction skills mattered far more than e.g. statistics
• The Right People
• Cross-functional teams
• Need a steering committee to get the people you need - want people who are strong not the weaker ones
• Availability is not desirability! Used focused interviews to explain issue to managers and find who would be the right team member (and get the manager bought in to providing them)
• People must be involved, knowledgeable and willing to be frank and honest so as to avoid group-think
• The Right Projects
• Managers have their own ideas for projects
• Succeed early and often! Find the right projects
• Match team skills to project
• Two wrong projects for example - Politically charged issues can be problematic. Small projects can burn goodwill.
• Fact-based decisions
• Management sometimes does not recognize that issues exist
• Must gather facts to show problem
• Match accuracy to the size of problem - perfect accuracy is not usually required.
• Implement
• Get it to happen or what was the point.

Frankly these aspects seem to me to be good general-purpose advice about projects. I am speaking tomorrow if you are attending.

Technorati Tags: agility, Business Process Management, organizational performance, six sigma

Posted by jtaylor in Business Agility • Innovation | Permalink | Comments (0) | TrackBacks (0)

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go.

First session was Thomas Koulopoulos on The Road to Agra: A View of Globalization from the Front Lines and the Back Streets. Thomas focused on innovation and globalization. He asked the audience what their core-competence is and tried to show, quite successfully, that only a focus on that and an innovation process can lead to success.

In a wide-ranging speech he covered how people's world view tends not to include the electronic networks that connect the planet and he used his experience of a trip in India, especially the road from Delhi to Agra (home of the Taj Mahal) as an analogy. He asked the question "What kind of economy will the US, or Europe, have if the developing world succeeds in its growth?" What is "special" about the US? He discussed how inter-reliance is both key and essential and how one should never underestimate the impact of compounding many small achievements.

His concern is that keeping the lights on in a complex organization is preventing from a focus on innovation

• Invention is science - comes from scientific method
• Creativity is art, the moment of creation
• Innovation is the process of intersection

He predicated that affordability is the most important driver for many recent innovations, as self-service was in the last century. In a world like ours, where more transistors were produced, more cheaply than rice last year the pressure between cost management and innovation is narrowing the acceptable range. You have less room for error. More than ever we need leadership and innovation.

Thomas' blog is at The Innovation Zone

I am speaking tomorrow if you are attending.

Posted by jtaylor in Business Process Outsourcing • Innovation | Permalink | Comments (0) | TrackBacks (0)

Well as my blog is linked to the Business Intelligence page I thought today's posting should be about decision management and business intelligence.In honor of this I have added a Business Intelligence category to the blog. This is the first posting in the new section, although I also edited a couple of others to add them to this category as they seemed relevant to BI.

So, what to write about....

Perhaps I should start by describing the difference between traditional BI, something most people understand, and what I call "Enterprise Decision Management" or decision management. I often use this graphic

Strategic decisions, in this model, are typically low-volume decisions taken by knowledge workers. Operational decisions, in contrast, are those taken in large volume typically by front-line staff or in a completely automated way. Tactical decisions are in the middle, typically about how to handle customers or processes.

The intent here is to show that the desire to run a more intelligence business (small-b business small-i intelligence) includes using analytic insight to drive strategic, tactical and operational decisions but BI (Business Intelligence in terms of software products) tends to focus on strategic and tactical decisions. Gartner calls the two approaches analyst-driven (more like traditional BI) and process-driven (newer analytic process automation techniques). This blog, you will find, is generally concerned with decision management and decision management technologies. Often what I do is comment on BI-topics from an operational perspective - what kind of technologies, approaches, mindset do you need to apply BI-like approaches in operational processes.

So, as you read the new BI section on ebizQ, think about the kind of decision you are trying to improve and be aware that different technologies might be suitable for each type. BI tools for some, rules and predictive analytics in an SOA environment in others.

There's a fair bit on BI and decisioning over on my other blog in the BI section.

Technorati Tags: BRE, BRMS, business intelligence, Business Rules, decision technology, predictive analytics, SOA, BI

Posted by jtaylor in Business Intelligence • Business Rules • Decision Technologies • Predictive Analytics • SOA | Permalink | Comments (0) | TrackBacks (0)

I saw this post on Nevant's blog about an item on TechReplublic entitled "Master the mundane with SOPs that fit". I found this fascinating as one of the uses of business rules is to automate the mundane. As the author says

"the best run organizations are those which have mastered the mundane"

SOPs are "written instructions to achieve uniformity of the performance of a specific function" and when it comes to the mundane in the business, not just the mundane in the IT department, using business rules to achieve this uniformity can be very effective. Not only can they be automated in a way that achieves mastery by creating SOPs and sticking to them, they can be easily and effectively changed by business owners to ensure that they are constantly evolving to be more effective. Thus automating the rules for paying claims ensures that all claims are handled quickly and consistently while empowering those who understand the claims process to change those rules when legal changes, policy changes or business changes demand it. As I said once before, if you need a policy manual, do you need a rules engine too?

It also occurs to me that business rules are a great way to implement a best practice approach while still considering the individual quirks of your environment. In fact using business rules to enhance the standard approaches embedded in your enterprise applications can be very effective.

Technorati Tags: Business Rules, organizational performance

Posted by jtaylor in Business Agility • Business Rules | Permalink | Comments (0) | TrackBacks (0)

I was reading David Chappell's blog last week he referenced one of his Opiniari on the difficulties of reuse, especially re-use of business logic, even when using a service-oriented approach. I have posted some recently about decision services and that made me think about re-use in the context of decision services. As David notes, the only surefire way to get reuse is to develop one service to replace all or part of several systems. Building a service, and hoping for reuse is often optimistic. So how does this change if I use a business rules management system to develop some or all of my services? How does that affect reuse?

• So firstly there is the question of reuse when building decision services. While I don't think decision services are inherently more reusable than other services in general, I can think of some that will often be reused because they are additive and not core to a process - like a service that generates recommended cross-sells. This will get reused precisely because it is not a core service. A small point relative to David's larger one, however.
• The second barrier he identifies is one of myriad minor variations of a service preventing reuse. This problem is not really any different with decision services. However, if I am using a common rule repository I may get reuse below the level of a service. Essentially a service designer might reuse many of the rules in a new service and the business rules management system will then manage changes to the services implied by changes to the rules. While this suffers from some of the same issues as reuse of services there are a couple of advantages. Firstly the reuse might be more granular - reassembling shared rules into a new service might work better for some developers than reusing the service. Secondly the business rules might be both more obviously shared, like rules defining customer segments, or might even be mandated by regulations and a need to comply with same. Lastly many business rules management systems allow for layers of rules and that might allow reuse of core rules with a layer of customized rules on top, supporting the minor variations needed.
• The last barrier is one of incentives - why should the first developer of a service even want others to reuse it? One of the great things about decision services build with business rules is that the owner of the service is, hopefully, the owner of the business rules. By and large these folks are highly motivated to share their services across the enterprise. Indeed it may even be policy. Think about a bank with a credit pricing service - a decision service that decides on the rate and terms for a credit product for a customer. The risk management group might own these rules and they want, and may be able to insist, on all processes that need credit product pricing use the service. This kind of service will get reused.

One final point. David implies that agility in SOA is just another word for reuse. I disagree. There is also the agility that comes from building a service so that the logic encapsulated in it can be changed readily. This intra-service agility can be as important, or more important, than the kind of inter-service agility that comes with reuse. Using business rules to develop this kind of service definitely adds agility. Reuse or no reuse.

Technorati Tags: agility, BRE, BRMS, Business Rules, decision service, SOA

Posted by jtaylor in Business Agility • Business Rules • SOA | Permalink | Comments (0) | TrackBacks (0)

I saw this article on bpm.com - Modernizing Legacy Applications. There was a lot to like in this article but I felt like it glossed over some critical issues in legacy modernization using BPM and SOA. Let's consider some of the quotes that struck me

• "Legacy systems contain vital business rules embedded within the source code"
• "Though programming languages have come a long way the emphasis is still on technology related artifacts rather than business rules and requirements"
• "But as important is the fact that many business rules are manual actions by people involved in the process and not programmatic code"

All this is true. But the answer is not to put these rules into a BPM tool but into a business rules management system. Doing this allows them to be managed, coded and maintained at a business rule level. It also allows for business owners to be engaged in managing rules and yet retains the flexibility to package up these rules into various services (in an SOA) or more traditional components (such as COBOL code).

This latter is important as sometimes it is the framework or process implementation in a legacy system that should be retained and logic within that framework that should be exposed as a service and managed as business rules. The California DMV's experience is a classic in this vein - the process of issuing registration has no changed in 30 years but the rules for fees change all the time. Keeping the legacy process, updating the fee calculation engine to use a business rules management system and then deploying these rules not only to the legacy system but also to other, newer systems as a service worked wonderfully.

So do think about business rules in your legacy systems, and about processes hidden within the portfolio of systems, but don't assume you must modernize the process. You may be able to just modernize the decisions.

Technorati Tags: agility, BRE, BRMS, Business Rules, government, legacy modernization, services

Posted by jtaylor in Business Rules • Decision Technologies • Legacy Modernization • SOA | Permalink | Comments (0) | TrackBacks (0)

I was pointed to this SOA message board thread where folks responded to the following question:

If the logic in a service is changed and f(x) begins producing a new result, do you version the service?
(Note: in this scenario, the interface didn't change just the internal logic.)

This came up in the context of a discussion I was having with Jeff Schneider over rules-based decision services. Opinion on the board seemed to be split. On one side there were folks who said variants on the theme that the behavior of the service behind its interface is equally important to the service consumer and so it should be versioned. Some folks were a little more precise and said that they would version the service if the difference in the result is semantically distinct. There was also a discussion around expectations - essentially that the interface should be versioned if the change to the logic would be incompatible or would change the expectations another service might have. As someone said "If the logic is relevant to the contract, yes, otherwise, no"

The question is what to do if the rules within a service change but the interface does not. Should you version the interface?

To me this comes down to an issue of context. If the business decision has not changed then the service has not changed and so the interface would not need to change. Thus if the changes to the rules change only the mechanics of making the decision (to comply with a new regulation or to take advantage of new understanding of customer segments for instance), then the interface should not be versioned because the service is doing the same job it was before. So I could change the rules in a service that answered questions like “Should I approve this person for this loan” or “is this claim fraudulent” or “what offers should I make” and not change the interface unless I changed the business intent. The fact that the rules have changed does not impact any other service until and unless I make a change to the business intent of the service.

When a business owner changes the rules within a service without changing the intent of the service I don’t consider that the service has changed. If I build a service that returns the most appropriate 3 cross-sell offers in descending order then as long as it continues to do that, why does a consuming service care how I figured out that the most appropriate three were? If I build a service that quotes for an insurance policy, why does a service that takes this quote and continues on with processing it care how the quote was calculated? Surely the purpose of encapsulation in a service is to mean I can rely on the service without having to understand its internals?

This kind of change is what makes rules-based decision services so powerful.

Technorati Tags: BRE, BRMS, Business Rules, services, SOA, decision service

Posted by jtaylor in Business Agility • Business Rules • SOA | Permalink | Comments (0) | TrackBacks (0)