#BRF Business Rules Conference Tutorials

This entry is part 1 of 24 in the series Business Rules Forum 2009

After a busy week blogging the October Rules Fest last week, I am attending the Business Rules Conference this week, including some of the tutorials that take place before.

So this will be the next series of posts covering the sessions I attend during the week.

So here it goes…

#BRF Smart use of Rules in Process Presentation

This entry is part 2 of 24 in the series Business Rules Forum 2009

Kathy Long is leading a tutorial on business processes.

A process is a repeatable series of activities that produces value for one or more stakeholders. It is more an art than a science. We need to understand inputs, outputs, guides and enablers.

Questions to answer to help us identify “What we do” (IGOE method):

  • What we need to do it?
  • What we produce or deliver
  • Why, When and How we do what we do?
  • Where we do it and What and Who we do it with?

Example: “To make Coffee”:

  • Inputs
    • Hot Water
    • Ground coffee beans
  • Enablers
    • Coffee Machine
    • Coffee Filter
    • Coffee Cup
    • Barista
  • Guides
    • Recipe
    • Documented experiences
  • Outputs
    • Hot coffee

How to decide between input and enabler? What is more important? For example the filter can be consumable but it can be an enabler.

We also need to decide where the exact start and end is. Otherwise, do we know if we have to also include sweetener, milk and cream, etc? The “boundaries” will be our guide to decide if this process needs to include that information. Also, try and limit the number of details (the need for electricity for example) because it would clutter the process being documented.

In a process box, the label should be and action and an object. Avoid ambiguous words such as “process” or “Manage”.

To help us do the analysis, start from the top and perform a “Process – Activity – Task – Step Decomposition”. break down processes in activities all the way to the task level. Don’t go too deep because you may end up documenting parts of the workflow that has a tendency to change (unless automated).

She then covered different methods with pros and cons

  • IGOE (based on IDEF)
  • Process Decomposition
  • BPMN Light
  • IGOE Flow
  • BPMN Full

She took some time to detail how to document the Guides from IGOE since this will be the link between the business process and the business rules. Business Processes can be broken down to Business Activities and then to Business Tasks. Business Rules will be defined as part for the Business Tasks. We walked through a “story” to show how to apply the “Guides” decomposition to it.

We would obviously need to do this exercise for Input or Outputs.

People have been trying to separate process and rules when they actually need to be worked on at the same time.

A lot of the presentation was explaining IGOE and how to use it. It is very interesting and made me realize that I may have been documenting things at a level of detail that may have been inappropriate.

My key takeaways from that tutorial

  • Standardization does not mean use only one notation, each notation has an audience that it applies better to
  • Stay at a higher level, don’t go all the way to the workflow level. Workflows are rarely accurate for very long (unless automated)
  • In a Business Process Model don’t model: Rules or Events

#BRF Capturing Business Rules Tutorial

This entry is part 3 of 24 in the series Business Rules Forum 2009

Gladys S.W. Lam is leading a tutorial about capturing business rules.

Some key concepts about business rules.

  • Built on Terms and Facts
  • Grouped by Decisions
  • Expressed in Business Rules Statements or Decision Tables
  • Applicable as explicitly indicated by stated Criteria
  • Managed by retaining elements of Traceability

They separate rules into governing, practicable and automated rules. Each level can be looked at for business processes and “know-how” rules.

The presentation then covered the methodology that they propose (Proteus which is available to download on the Business Rules Solutions web site).

These questions allow you to start capturing the rules:

  • What – Structure: Fact Models & Concept Catalog – Rules: Consistency
  • How – Transformation: Business Process Model – Rules: Calculations & Transformations
  • Where – Geography: Business Connectivity Map – Rules: Transport & Linkage
  • Who – Interaction: Organizational Work Model – Rules: Organizational Interactions
  • When – Time: Business Milestones – Rules: Timing & Intervals
  • Why – Motivation: Policy Charter – Rules: Exceptions & Priorities

Using facilitated sessions for rule capture. Success factors for facilitated sessions are:

  • Having the right people in the room
  • A lot of preparation is required

Procedures to use facilitated sessions:

  1. Prepare for requirements gathering sessions
  2. Conduct requirements gathering facilitated sessions
  3. Analyze and document business model
  4. Prepare for detailed business rule analysis
  5. Conduct business process rule facilitation session
  6. Analyze and document business process rules
  7. Capture business know-how rules

To define scope, use the six questions: what, how, where, who, when, why. If any answer changes as you are working, that is indicating scope creep.

The presentation then went into some details of the approach and showed how it can be applied.

My takeaways from this session:

  • This information can be used as a starting point for educating people working on a rules project
  • Using that methodology might give a bit more structure to the work I already do with customers

#BRF Using Business Analysis Tutorial

This entry is part 4 of 24 in the series Business Rules Forum 2009

Kevin Brennan is leading a tutorial about Business Analysis.

He introduced the International Institute of Business Analysis (IIBA at theiiba.org) as a relatively young organization for Business Analysis.

Business Analysis is:

  • Analysis is
    • Taking a thing, breaking it into its components parts to build a useful model of the organization.
  • About a Business
    • (no kidding!) 🙂

The value of Business Analysis

  • Understanding
    • how an organization works
    • why it exists
    • what are its goals and objectives
    • how it accomplishes those objectives
    • how it needs to change to better accomplish objectives or to meet new challenges
  • It’s about
    • meeting business needs
    • ensuring investment in the right solutions

The IIBA create the Business Analysis Body of Knowledge (BABOK) reference. A lot of the contents relates to the PMBOK and it shows that there needs to be a relative closeness between the Project Manager and the Business Analyst.

The Body of knowledge relates to:

  • BA Planning and Monitoring
  • Elicitation
  • Requirements Management and Communication
  • Enterprise Analysis Structure
  • Requirements Analysis Structure
  • Solutions Assessment and Validation

Underlying competencies that are required (the slides were more detailed, but the main categories were):

  • Analytical Thinking and Problem Solving
  • Behavioural Characteristics (ethics, personal organization, trustworthiness)
  • Business Knowledge
  • Communication Skills
  • Interaction Skills
  • Software Applications

Core Business Model of an organization that a BA must work on:

  • Decisions and Rules
  • Tasks and Processes
  • Roles
  • Concepts and Relationships
  • Events

The presentation then covered other topics, looked at some numbers used to prompt the topics of discussion, all of it very interesting but which I thought was difficult to blog about properly. Good presentation overall.

My takeaways from that session:

  • I got a quick overview of the contents of the BABOK
  • I have a better understanding of the competencies that a BA should have

#BRF Introducing a rules methodology part 2 Presentation

This entry is part 5 of 24 in the series Business Rules Forum 2009

Kathy Gorman and Kristen Seer are doing a follow up presentation from last year’s presentation on introducing a rules methodology.

The methodology is important, but the infrastructure to support it is also very important.

ICBC is a crown corporation for compulsory auto insurance. Some optional insurance in a competitive market. Network of brokers, 5000 employees, etc. They are working with Business Rules Solutions.

The Drivers for changes at ICBC:

  • challenges to support cross-functional projects
  • Significant time frames for business analysis
  • No common, formal methodology
  • Current analysis approach better suited to maintenance versus delivery of enterprise transformation initiatives

Creation of a Business Transformation Services group to lead the changes, merged the BA practices from different silos. They created a position called “Manager of Best Practices” to help with the changes.

They have a very defined line between business and IT. The Business Analysis is really a Business Function. They followed an iterative approach.

Over time they had the following accomplishments:

  • Organisational Structure changes
  • Competency Model that identifies what skills people need to have
  • Enterprise Delivery Life Cycle, not rolled out, but being used by the BA group
  • Purchase of Business Rules Methodology
  • The Service Model for BAs has been improvements
  • The Competency Model is also driving a Resource Assessment based on the model
  • Performance Measurement was also introduced (KPIs around service model) and a Quality review process.
  • Put together an Estimation Model which focuses on components of the methodology

The methodology components

  • Approach Model: Technique for BAs to sit down and figure out how they are going to do their work to establish expectations
  • Business Scope: From a Business perspective how big is this
  • Business Strategy: Looks at goals and tactics and what risks might arise and mitigations
  • BPM
  • Fact Model
  • Business Rules
  • Business System Abilities: Functional-Non Functional Requirements

They developed an approach model for implementing the methodology itself.

The tasks were:

  • Communicate to staff and stakeholders
    • You can’t communicate enough
    • The created a communication plan for all stakeholders
    • Need to tailor presentations to the audience but need to keep them consistent
    • The focus has shifted from pushing information and now people are asking more questions now
    • Developed a Web Site (competency center with standards, guidelines, etc.)
    • Announcements sent for the web site updates on a regular basis
    • Team Meetings have a standing item to discuss the methodology
    • “Open House”, Presentation or workshops followed by Q&A
    • To improve attendance at Open House, look for patterns of what BAs are talking about at that time
  • Establish Governance
    • Created a “Practice Manager Position”
    • Competency Center
    • Methodology Evolution Team (Governing body for the methodology)
      • Need to educate them with white papers followed by discussions to adapt the methodology to their needs
      • Now looking at how to evolve this over time
    • Model Management
  • Conduct General Training
    • Training sessions and reinforcement training to keep the skill level going if not applying
    • Also created session for partners and project managers
    • Videos of the sessions and edited to about 10 minutes in length for a specific topic
    • One on one mentoring
    • Review process is “pre-reviewed” with some help
  • Adopt BRS methodology
    • Full set of reference materials
      • Standards and guidelines
      • Templates
      • Quick reference guides
      • FAQs
    • Requirements to Design Handshake (in progress) (from BA to the IT group)
      • More than a handoff
      • Handshakes designed for each “design deliverable”
      • Next challenge will be roll out and communication strategy
    • Develop of tools to handle gaps
    • Process to evolve the practice
  • Pilot BRS Methodology (Challenges)
    • They ended up not piloting
    • Needed to apply faster than expected
  • Audit Implementation

Challenges they encountered

  • Socialization and Orientation of Partners is more time consuming than expected
  • Repositioning of Business Participants
  • Lack of core skills (such a facilitation)
  • Reaction of partners, sometimes reluctant
  • Misconceptions
  • Size of the transformation (change is difficult for the people)

Lessons learned

  • Prepare for a difficult transition
  • Ongoing mentoring & coaching is critical
  • Communicate, communicate, communicate
  • Anticipate & plan for resistance, be prepared to shift course
  • Getting to independence (takes a long time), need support structure
  • Don’t underestimate cultural shift
  • Manage the expectations of managers

#BRF Making Better Decisions in the Face of Uncertainty Keynote

This entry is part 6 of 24 in the series Business Rules Forum 2009

Jim Sinur is giving the keynote at the Business Rules Forum in Las Vegas this morning.

When software spending increased about 3% in a down time, in BPM the increase was over 23%. This indicates that BPM saves money.

Change is constant, not a variable. Signs from the market and economic factors, customers and vendors are warning signs.

Current organizational models for exception planning has anticipated exceptions and unanticipated exceptions. Anticipated exceptions are sometime recognized and we react to them. Unanticipated exceptions have no plan and are reacted upon through gut feel.

CEP involves one order of magnitude or two more information than what companies currently deal with.

Companies can’t keep looking at what was happening in the past. They have to look forward by identifying patterns in the information we have available. We need to look for patterns in people, information and processes.

What can you do?

  • Seek patterns that may have a positive or negative impact on your strategy
  • Model Pattern Impact on Strategy and Operations
  • Adapt. Decide and execute change

4 disciplines needed for pattern based strategy:

  • Pattern seeking
  • Operational tempo Advantage to improve an organization reaction time
    • Empower people
    • Coordinate Processes
    • Share information
  • Performance Driven culture
  • Transparency

Partial (because I couldn’t write them all) List of Technologies to support the Seek-Model-Adapt:

  • Seek
    • Predictive Analytics
    • BI “on steroids”
    • CEP
    • Decision management
  • Model
    • Critical Path modeling
  • Adapt
    • Business Rules Management
    • Business Process Management
    • Business Activity Monitoring

#BRF BPM, Collaboration and Social Networking Presentation

This entry is part 7 of 24 in the series Business Rules Forum 2009

Sandy Kemsley (www.column2.com) is speaking about BPM, Collaboration and Social Networking at the Business Rules Forum in Las Vegas.

How do you bring Enterprise 2.0 in BPM. A few years ago, Sandy had talked about how BPM and Enterprise 2.0 would integrate a couple of years ago. Some of her predictions became real, some didn’t.

She did a quick review of what BPM is and what is in a BPMS.

What is Web 2.0

  • Consuming-facing social software (facebook, gmail, youtube, etc.)
  • Software as a service
    • For example: Google Apps.
  • Harnesses collective intelligence through user-created content
    • For example blogs or twitter
    • Create content with very low barriers
    • It is valuable because the conversation is taking place with people in different places around the world
  • Lightweight development models permit mashups (composite applications)
    • Allows taking bits and pieces from different places and put them together. Some combinations were not necessarily planned, but the flexibility of the APIs allows their pairing.

Web 2.0 Examples:

  • Gmail: rich interface and constantly upgraded feature sets
  • Wikipedia: content contributed by many authors
  • Google Maps: open API allows combining with many other web apps

All the knowledge is in the enterprise and the ability of capturing that information is invaluable by leveraging social software in the Enterprise 2.0.

Business Purpose of Social Software in the Enterprise 2.0:

  • To strengthen weak ties with people in a company or with customers and partners.
  • Social production to collaboratively produce content

There are now software that allow companies to provide that functionality within the enterprise instead of going to Software as a Service. For example, IBM uses something called “Beehive” internally to strengthen connections within the company. As a another example, the US Intelligence community is using a wiki type software to gather intelligence information.

Organizations need to have a cultural shift to allow people to leverage these social technologies in the Enterprise.

The drivers for BPM and Enterprise 2.0 are:

  • Users expectations are changing
  • Trends towards greater collaboration
  • There is a lack of agility in many current BPMS implementations

3 manifestations of collaboration in BPM

  • Collaborative process modeling
    • Multiple people participate in discovery and modeling of processes
    • Capture “tribal knowledge”
    • Internal and external participants
    • Technical and non-technical participants
    • Examples: Lombardi Blueprint, SAP Netweaver BOM with Google Wave
  • Collaborative process execution
    • User can “step outside” a structure process and create ad hoc collaboration
    • Audit trail and artifacts captured within BPMS audit log
    • Eliminates uncontrolled (unaudited) e-mail processes
    • Examples: HandySoft, ActionBase
  • BPM and Social Networking
    • External communities of practice (or centers of excellence)
      • Example: IBM Blueworks, Appian Forum, SOftware Ag Alignspace
    • Internal discussion forums and collaboration linked to specific process models or instances within the BPMS
      • Examples: Appian, Global 360

Impacts of Social Networking with BPM

  • Social and Cultural Impacts
    • The Business needs to commit resources and “bless” that approach
    • IT must allow business to participate
    • Users must feel comfortable getting away from their previous way of working
  • Technological Impacts
    • Standardized feeds for repurposing data. Let the user customize the information they see.
    • Instant messaging or microblogging for process alerts
    • Rich user interfaces eliminates desktop installation
    • User-created “mashups”
  • Economic Impacts
    • Shift from (perceived or actual) high BPMS costs to lower-cost alternatives
    • Rich Internet Application and lightweight development models lower development costs
    • Software as a service BPMS lowers capital costs

Barriers to adoption of Enterprise 2.0 and BPM

  • Perceived loss of control over processes (needs cultural change)
  • Lack of understanding and trust in lightweight development models and tools
  • Risk of data loss or security breach with SaaS BPMS
    • Sandy says that she uses SaaS for her business and after doing a due diligence you need to trust that the vendor is spending more time and money making sure that this won’t happen. If they don’t do that, they will loose your business.

The Future (is already here)

  • Many BPMS vendors incorporating some Enterprise 2.0 functionality
  • These are facilitating change in BPM

The Future

  • Tagging or bookmarking of instances of process
  • IM or other synchronous communication integrated
  • Goal-oriented process responsibility from management to knowledge workers

Very interesting presentation that shows us where things are and where they are going as far as the social networking tools and BPM. I think a lot of that can be extrapolated to topics that go beyond BPM.

The slides will be available on her blog shortly.

#BRF Business Rules enhance agility in BPM presentation

This entry is part 8 of 24 in the series Business Rules Forum 2009

Dr. M. A. Ketabchi is presenting. He covered a quick definition of BPM.

The classic BPM Cycle:

  • Model
  • Execute
  • Monitor
  • Improve

Key Values of BPM

  • Visibility
  • Agility
  • Efficiency
  • Business Empowerment

The Roles of rules in Business Process Management

  • Smart performer
  • Intelligent work allocation
  • Intelligence decision support (BRMS)
  • Smart forms (Dynamic Forms)
  • Real-time business applications (CEP)

BPM Usage Patterns that need rules

  • Decision Centric
  • Event Centric

BPM benefits from Integrated Rule Functionality

  • Agility
    • Rules can change dynamically independently from processes
  • Simplicity
    • Expressing declarative logic is process solutions with rules simplifies process solutions
  • Ease of Automation
    • Most business solutions required both procedural and declarative logic
  • Real-time Interoperations
    • Event rules can correlate events from multiple sources in real time

There are 2 approaches at providing BPM and BRM functionality

  • BPM in a Rule Language (one cannot be used and changed without the other such a PegaSystems)
  • Integrated BPM and BRM (both functionality are available and integrated out of the box) This is the approach that Savvion takes so only that one will be detailed in this presentation.
    • Rules can be developed, tested, managed independently of process
    • Ability to change rules at different time independently of processes (isn’t that the same as the first one??)
    • Same rules can be shared by multiple processes

Concluding remarks;

  • BPM suites require different types of rule functionality
  • Data and event driven rules support is critical

The presentation almost lost my interest when they started talking about the Savvion product and functionalities right at the beginning. It felt like it was going a marketing presentation. Luckily that lasted only a couple of minutes.

From that presentation (and other discussions that happened last week and this week) it seems that there seems to be more and more convergence between Business Rules, CEP and BPM.

#BRF Enabling Effective Business – IT Collaboration Presentation

This entry is part 9 of 24 in the series Business Rules Forum 2009

Rik Gerrits, Colleen McClintock and Linda Nieporent are presenting.

Business Rules Management Contexts

  • Corporate artifact (policies and regulations, publications, regulatory compliance)
  • Requirements artifacts (application independent and application specific
  • Executable code

BRM at the corporate level is for the sake of the business, of, by and for the business, independent of hardware and software and of a specific solution.

Requirements are for the sake of systems and applications, of, by, and for the Analysts. The requirements are global or specific to the application.

Execution is expressed in a way that a rule engine can interpret, validate and execute. It is for IT people. Always in the context of a specific solution.

The first part of the presentation move very slowly. It was not providing a lot of new information since the main goal of it was to highlight what functionality you would be needed by a system to manage rules in the 3 contexts that they presented. It sounded like a setup for a marketing presentation to show that RuleArts’ RuleExpress tool provides.

The presentation turns out to be a demo of an integration that RuleArts did with JRules. The customized some of the information that is visible in RuleExpress and extended properties in JRules so that in Team Server you can see some information that comes from the RuleExpress. Interesting integration, but still has flaws.

Some of the flaws that come to mind:

  • You end up with 2 repositories
  • There is no synchronisation of the models (vocabulary and BOM)

I guess the main point they made is that chances are that in an organization you will have multiple representations of rules and that to support that you can create tools that allow synchronization between those different tools and that this integration is one way to help business and IT collaboration.

I just wish I had known it would simply be a demo of the integration and that there would not be much (not as much as I was hoping for) other added value in the presentation.

#BRF Enabling Effective Business – IT Collaboration Presentation

This entry is part 10 of 24 in the series Business Rules Forum 2009

Rik Gerrits, Colleen McClintock and Linda Nieporent are presenting.

Business Rules Management Contexts

  • Corporate artifact (policies and regulations, publications, regulatory compliance)
  • Requirements artifacts (application independent and application specific
  • Executable code

BRM at the corporate level is for the sake of the business, of, by and for the business, independent of hardware and software and of a specific solution.

Requirements are for the sake of systems and applications, of, by, and for the Analysts. The requirements are global or specific to the application.

Execution is expressed in a way that a rule engine can interpret, validate and execute. It is for IT people. Always in the context of a specific solution.

The first part of the presentation move very slowly. It was not providing a lot of new information since the main goal of it was to highlight what functionality you would be needed by a system to manage rules in the 3 contexts that they presented. It sounded like a setup for a marketing presentation to show that RuleArts’ RuleExpress tool provides.

The presentation turns out to be a demo of an integration that RuleArts did with JRules. The customized some of the information that is visible in RuleExpress and extended properties in JRules so that in Team Server you can see some information that comes from the RuleExpress. Interesting integration, but still has flaws.

Some of the flaws that come to mind:

  • You end up with 2 repositories
  • There is no synchronisation of the models (vocabulary and BOM)

I guess the main point they made is that chances are that in an organization you will have multiple representations of rules and that to support that you can create tools that allow synchronization between those different tools and that this integration is one way to help business and IT collaboration.

I just wish I had known it would simply be a demo of the integration and that there would not be much (not as much as I was hoping for) other added value in the presentation.