Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

How Important is Basic Business Vocabulary? … A Short (True!) Story

Guest Post I was teaching a BA class, trying to convey the value of having a prototype. The class was divided into ‘developers’, the BA, and the ‘executive’. The developers were given a bag of duplos, multiple shapes and colors. The executive was given a bag with a completed duplo creation. The instructions were for the BA to elicit information from the executive and provide it to the developers so they could build the creation. What I discovered is that they needed a common language (terms everyone knew the meaning of), and a frame of reference (location, name of layers or identity of corners, etc.). Without this information, communication was impossible.  After they created these ‘handles’, they were able to communicate and convey information. The value of having a prototype was demonstrated.  The value of common terms and clear understanding was priceless! ~~~~~~~~~~~~~ Acks: Thea Rasins Consultant, Educator and Professional Organizer KCIIBA Board Member and Vice President of Professional Development

Continue Reading 1 Comment

The ‘Process’ of Business Analysis is a Great Example of a Social Process

In a recent post, Jonathan ‘Kupe’ Kupersmith said:

“In manufacturing following a process step by step is a good thing. In our world [business analysis] this is not the case.  Following an A to Z process for every project is a bad thing.  Every project is different.  Different people, different risks, different priorities, etc.  You need to adapt your process to meet the needs of the project.”.

I believe what Kupe is saying is that the ‘business analysis process’ is not a traditional straight-line process (like old-style manufacturing). Instead, it is what is currently being called (variously) a ‘social process’ or ‘dynamic process’ or ‘case-based process’. Such a process is:
  • Social in that interactions at various times with various people with various kinds of know-how must be orchestrated for optimal results.  
  • Dynamic in that the ‘flow’ is highly situation-based rather than predictably straight-through (static).  
  • Case-Based in that the ‘flow’ of events is based on the particular characteristics of the case (project) at hand, rather on forced conformance with some ideal.
Let me make a couple of observations (which are not points of disagreement with Kupe): 
  • There are many, many companies (even in manufacturing) now beginning to understand that their core business processes should be organized as social/dynamic/case-based rather than traditional/static/straight-line. Customization and personalization of products and services demand it.  
  • Achieving manageable customization and personalization at scale requires an appropriate infrastructure that is business-based.  
  • The need for infrastructure leads inevitably to business vocabulary (business semantics) and business rules. (What’s the alternative??) So business rules are probably even more essential for social/dynamic/case-based processes than traditional/static/straight-line ones.
What do these observations specifically mean for the ‘business analysis process’? I would suggest the following: 
  • Having a standard business vocabulary for the ‘business analysis process’ is key. How many organizations really have one? I see this omission as a huge hole in current BA standards and practices. (Plug: Our new book, Building Business Solutions: Business Analysis with Business Rules, has a 55pp Annotated Glossary. We practice what we preach. http://www.brsolutions.com/b_building_business_solutions.php)  
  • The know-how to support a social/dynamic/case-based ‘business analysis process’ should be expressible as rules. If the know-how can’t be articulated and properly communicated, then how can the process be repeated, learned and scaled? Tacit know-how is simply no longer adequate in a knowledge economy.
~~~~~~~~~~~~~~~  You can find Kupe’s original post on: http://www.batimes.com/kupe-kupersmith/why-business-analysis-processes-are-a-waste-of-time.html

Continue Reading 2 Comments

Requirements and Business Rules … All Just a Matter of Semantics (Really)

It almost goes without saying (but I’ll say it anyway) that you must know exactly what the words mean in all parts of your business requirements. In running a complex business (and what business isn’t complex these days?!), the meaning of the words can simply never be taken as a ‘given’. Some IT professionals believe that if they can model the behavior of a business capability (or more likely, some information system to support it), structural components of the know-how will somehow fall into place. That’s naïve and simply wrong. Business can no longer afford such thinking. A single, unified business vocabulary (fact model) is a prerequisite for creating a scalable, multi-use body of business rules – not to mention good business requirements. It’s what you need to express what you know precisely, consistently, and without ambiguity. Certainly no form of business rule expression or representation, including decision tables, is viable or complete if not based on one. And I pretty certain that’s true for most other forms of business communication about day-to-day business activity too. What am I missing something here?  ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading

Is Agile Development of Business Rules Possible? … And What Would You Call It If It Is?

I’ve been exploring the meaning of ‘agile’ with respect to business rules. In our new book, we say:

Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing. All artificial (IT-based) production freeze dates for deployment disappear and the software release cycle becomes irrelevant. The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to.”

In response, a practitioner made the following deeply insightful observation about agile development of business rules.

Practitioner: “My perception of the intent of agile software development is to try to have the underlying development process track better to the realities of the business process change. Rather than the good old days where the specification and implementation of the solution ran so long that the problem trying to be solved had changed so much that the delivered solution was irrelevant.  So, if you reach a point where ‘The only constraint is how long it takes business leads and Business Analysts to think through the change’, then, to me, you are already doing agile development.”

Just to clarify: Our underlying assumption is that business policy and business rules can be and should be specified and analyzed independently of traditional software requirements (i.e., functional and non-functional requirements). That’s rule independence as the Business Rules Manifesto calls it. Business rules can and should have an independent life cycle. Then yes, there could be two kinds of ‘agile development’. Agile development of business rules and agile development of software. (I’ll leave it to others to decide whether agile development of requirements makes sense.) But here’s the rub: If you did reach the point where ‘the only constraint is how long it takes business leads and Business Analysts to think through the change’ in business rules – and I do believe that’s possible – business managers almost certainly wouldn’t (and shouldn’t) call it ‘agile development’. That’s an IT buzzword. When you talk about development of business policy and business rules, you are really talking about governance. Here is the Merriam-Webster Unabridged definition of “govern” …

1a: to exercise arbitrarily or by established rules continuous sovereign authority over; especially : to control and direct the making and administration of policy in

Note the prominent appearance of ‘rules’ and ‘policy’ in that definition. Hey, I didn’t make it up, it’s right there in the dictionary(!). So the bottom line is this: Instead of ‘agile development’ of business rules, at that point I’d say you’d be talking about agile governance. Indeed, I believe that’s exactly what we’re getting at here. Very exciting once you see it! ~~~~~~~~~~~~~~~ Our new book (Oct, 2011): Building Business Solutions: Business Analysis with Business Rules – See:  http://www.brsolutions.com/b_building_business_solutions.php By the way, we call the “it” in “… once you see it” an elephant. Have a look at the book to find out why.

Continue Reading 1 Comment

Scary Estimate about the Correctness of Business Rules in Legacy Systems … Are Yours Better or Worse? Do You Even Know?

A business analyst at a major insurance company recently said this: “When we looked hard at business rules currently implemented in existing systems, we found at least 30% were flatly wrong. That’s a very conservative estimate: the actual figure was probably much higher.” How does that estimate compare to yours? Have you ever done an assessment? I’d like to hear about it. The replies can be anonymous … like this one … DM me or use LinkedIn. By the way, the business analyst went on to say, “ IT told us they couldn’t solve the problem because it was a business issue not a software issue. And they were absolutely right about that.” Yes indeed they were. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Text excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

Continue Reading 1 Comment

Thou Shalt Not Kill … Could Anyone Mistake that Commandment for a Process?! Or the Process with a Concept?

My Analysis: There are three clearly different things involved here …
  • The process of murder transforms a live person into a dead person by killing them.
  • The concept of murder is defined as the act of killing someone.
  • The rule about murder is that there shouldn’t be any of them.
The first is about doing; the second is about knowing; the third is about prohibiting. Three very different things. So it should be in business analysis and analysis of business rules.  ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading 1 Comment

What is Agile? … Or Rather, What is It We Really Want to Be ‘Agile’?

This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php ~~~~~~~~~~~~~~~~~ Agile in software development is an IT development method featuring rapid iteration and prototyping. Agile software methods and business agility have nothing to do with each other. Agile in software development leaves off exactly where business agility picks up – at deployment. In working with clients we frequently come across systems that feature a very ‘open’ environment with few enterprise controls. Typically, this ‘flexibility’ resulted from diligent efforts by IT to satisfy many stakeholders individually. But the ‘flexibility’ is just an illusion. The failure of business-side stakeholders to come together and develop a collective business solution before ‘agile’ software development commences can plague the company for years to come. It reduces overall productivity, lowers customer satisfaction, and diminishes the capacity to make sound operational business decisions. It makes apple-to-apple financial comparisons virtually impossible. And it always costs a lot in ‘maintenance’. There are simply no magic bullets for building business solutions. Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing. All artificial (IT-based) production freeze dates for deployment disappear and the software release cycle becomes irrelevant. The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to. So the answer to my question is that business should be agile. Here then is our definition of business agility: being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and Business Analysts can determine the full business impact of the change and assess whether the change makes good business sense.

Continue Reading 2 Comments

Something Important All Business Analysts Owe to Business People … Probably Not Something You’d Expect?

One of the first rules of business analysis should be never waste business people’s time. One of the fastest ways to waste their time is not knowing what they are talking about … literally … and do nothing about it. So you end up just wasting their time over and over again. Unacceptable. Is there a way to avoid it? Yes, by taking the time to understand exactly what concepts the business people mean when they use the words they use.  I believe business vocabulary should be job one for Business Analysts. If you don’t know (and can’t agree about) what the concepts mean, then (excuse me here for being blunt) you simply don’t know what you’re talking about. (And sometimes, unfortunately, neither do the business people … which is something important BAs should find out as early as possible.) So structured business vocabularies (fact models) are a critical business analysis tool. How else is there to analyze and communicate about complex know-how in a process-independent way?! Looking at the issue the other way around, you can make yourself look really smart about a complex area in a relatively short time by having and following a blueprint. We’ve had that experience many, many times in a wide variety of industries and problem areas. (Try jumping between insurance, pharmaceuticals, electricity markets, eCommerce, race care equipment, credit card fraud, trucking, taxation, healthcare, banking, mortgages, pension administration, ship inspections, and more! We do.) There’s no magic to it – like contractors for the construction of buildings, you must have or create structural blueprints. For operational business know-how, that means bringing an architect’s view to structure the concept system of the problem space …  just a fancy way of saying develop a well-structured business vocabulary. Then a whole lot of things will fall right into place for you. P.S. By the way, I’m not talking about any form of data modeling here. Also, there’s no real need to use the ‘S’ word (semantics) for it.  

Continue Reading

Business Process Models and Business Rules … Separate the ‘Know’ from the ‘Flow’

Business Process Models and Business Rules … Separate the ‘Know’ from the ‘Flow’ Conditional flows are one of the most important features of a business process model. For example, a business process model for handling claims would include multiple conditional flows – e.g., if valid claim, if claim approved, if fraud suspected, etc. A conditional flow simply means that work follows the given path only if the condition is satisfied for a given case. The secret of effective business process modeling with business rules is never embed the criteria used to evaluate a conditional in the conditional itself. Instead, just name the conditional using an adjective (e.g., valid) or past participle (e.g., approved). The criteria for evaluating conditionals should always be expressed separately as business rules. Fortunately there’s nothing particularly hard about that. Example: A claim may be considered valid only if it has an incident date. Following this best practice is how you keep a business process model simple – often by an order of magnitude or more! Frankly, most business processes aren’t nearly as complicated as people think. What’s complicated is the know-how needed to perform the business process correctly. That know-how should be represented by business rules. P.S. I first heard the phrase ‘separate the know from the flow’ from Roger Burlton on 11/30/1999. I immediately made a note because it was so memorable and on-target.  ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading

Just Organizational or Application Silos? … Worse, You Have Semantic Silos

Difficulties in communicating within organizations are by no means limited to communications among business workers, Business Analysts, and IT professionals. In many organizations, business workers from different areas or departments often have trouble communicating, even with each other. The business workers seem to live in what we might call semantic silos (reinforced by legacy systems).  A well-managed, well-structured business vocabulary (fact model) should be a central fixture of business operations. We believe it should be as accessible and as interactive as (say) spellcheck in Microsoft Word. Accessible business vocabulary should be a basic element in your plan for rulebook management, requirements development, and managing know-how.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php    

Continue Reading