The Better Business Analysis Institute presence, the Better
Business Analysis Podcast with Kenjan Walsh.
Hi, everybody, and welcome back to the Better Business Analysis
podcast with Benjamin Walsh. And we're continuing our BA Byte
series. And today we're talking about
business rules and why they're so confusing.
Business rules, I find, are one of the areas that aren't talked
about much in business analysis. They don't really have a
structured format in terms of how you should follow them or
the pattern in terms of how you should write them.
And I think they're one of the most misunderstood pieces of the
puzzle when it comes to business analysis.
So let's dive in. What is a business rule and why
it might be different to what you think of business rule is
and why you may need to change your mindset when it comes to
business rules. So business rules are scenario
rules that come from the business, which are driven by
legislation changes or what the business wants, right?
And they're defined for the business and then they can
translate to how the machine, the business machine operates.
So you've got requirements, which of course are requirements
either within a change process or for something you're telling
or defining what you want the system or solution to do.
These are now scenario rules. Here's an example.
A simple example would be a customer needs to be 18 to open
an account. That's the business rule, and I
like the way that's structured. A customer, one of our actors,
needs to be 18, a defined variable to open function, which
of course open an account would be a requirement here.
And then account, an account is one of our business entities.
That's a really great example of our business rule, and that's
actually the format in which you should write it.
A more complicated example would be a discount depends on the
customer's loyalty tier, and then that could reference maybe
Excel spreadsheet, a table or a matrix which had the lists of
the discounts and the loyalty tier.
Nothing in there is defining how the code should be written.
And this is where B as get mucked up.
This is where B as go too low or don't think it's their job to
construct business rules or it's the technical team asking for
rules to be filled in. Once they're building the
solution, they should all be done up front before a solution
is defined. In order to make your business
rules better, we need them to be.
We need to have like some consistent way of defining them.
OK. Business rules are things where
decisions can be made. There there there are a a prime
point where you should review business rules when you're
making a change to a system or a product.
And a lot of times actually you may just be changing business
rules. An example here would be of a
piece of legislation came out that changed how old you needed
to be in order to get your driver's license.
Let's say, let's say it was reduced from 18 to 16.
That could translate directly to a business rule for the
government department that issues driver's license that
there may there would might be a change project.
Of course there would be a change project to implement.
OK, what does that mean? OK, well, this legislation could
will go two ways here. One, we've got a business rule
and then we've got business requirements off there issuing
what we print on the IDs, how we check people's ages, maybe based
on passports or whatever. So all of those which are just
the process requirements, which would drop out because it's the
process problem and a policy problem.
And then the business rule would be OK, we've got a legislation
change here from 18 to 16. That's the business rule.
So that's a business rule change.
And that's exactly the language we need to use are the benefits
of defining a business rule as an explicit statement and maybe
even having them in an explicit list so you can pull them out
because they exist regardless of the solution that you have put
in place. Refer back to them and you can
check them from time to time. And you should do that as a
business. Business rules provide less
confusion, OK, and less waste figures figuring things out.
Business rules are really important.
If you document them, then you can really see any legal or
regulatory requirements or policy requirements.
They generally come from organization or policy
requirements or environmental requirements that you need to
adhere to. But the business can also adopt
their own rules which are hence the word business rules.
They help with decision making and it helps everyone understand
why behind the decision and when you write them.
Here are some key points you need to me make sure that you're
using plain language. Everyone in the business can
understand everyone. Probably everyone outside the
business can understand. You need no room for
interpretation. OK, there are almost terms and
conditions here. Clear terms and conditions.
I'm not talking about going to the legal department, but
sometimes you might need to if you really want to get clear on
a point. But then you want to reinterpret
that into business language and refer to the document.
If people want to understand what you mean by some of the
definitions or some of the terms you're using, you need to focus
on outcomes. State the desired result, not
the specific steps, OK, unless they are critical in the
business rules. So for example, if customer
chooses X then Y, if they choose A then then B.
But that's the only only if that is affecting the scenario of the
business rule. Otherwise state the desired
result which has maybe providing discounts to customers.
Test and refine them with your stakeholders and revise them.
And actually some of these business rules, not the system,
not the product, are things you could test, AB test.
You could say, OK, well one of our business rules is we're not
going to provide loans to people with bad credit ratings, right?
Under a certain threshold that could that's a business rule.
And you've applied that into the system.
You're like, well, we're testing this.
So you could have a flexible business rule in the system.
And then maybe you're like, actually a whole business model
will fail business, business model, business rule that we
will now open up some loans, a smaller amount of money to
people with better credit ratings, but we're not gonna
have as high risk. So we're not gonna loan them
large amounts of money. And actually we've defined that
we've had our sweet spot. So these business rules need to
be malleable and they need to be able to change at some point.
I'm going to now talk to you about what business rules are
not. So we've talked about that.
Business rules are almost Co equal with other requirements
such as process model requirements, where a lot of
requirements come from, right? They're the rules that govern
the process sub process steps or how you carry out the procedure.
They are definitely part of the model year.
So you need to put them under your requirements, your user
stories, and they do drop out of process steps.
So a business rule guides the behavior and the decision making
within the organization. So it's what actions can they
take under what conditions. Whereas a system rule governs
the behavior of the specific system or solution and and B as
need to walk a tightrope here. I think there was a term I used
this week. System rules dictate how the
system processes datas and performs calculations.
Some of the rules are written so in the system, as in we've we've
said we want to implement. If someone has a bad credit
rating, do the following thing. We've, we've only ever defined
that in the system to say, oh, when we hit the system step in
the, I don't know, SQL procedure, we're going to pump
them out. Business rules can relate to
system rules, code code rules, but the business rule comes
first. Do you need, if you've got
those, if you're in a current state where you haven't actually
defined your business capital B business rules, pull them out.
OK, so you can do that with your current state.
You can go through and go, hey, look, I'm going to spend the
day, I'm going to write up all our business rules.
We don't actually have them defined.
They're all baked into our code and that's why we're stuck with
the system we've got. It's one of the reasons why we
don't have optionality. So I'm going to go through, I'm
going to interview the the DBA or the developers and I'm going
to pull out some of these rules so they're clearer to our
product owners, to the business, so they understand what's baked
into our process. This happens often and I'm sure
you're in this situation too. Whereas no one actually knows
what the rules are that were applied.
It's just legacy. And so by pulling those out and
defining them, you can actually take stock and do an audit, a
business rule audit, which I think is really good for BAS to
do. And the other thing that
business rules really talk to is, is flexibility that business
rules can change business changes.
And things like the fact that we had system rules in place for
GST or VAT which were baked into our systems or we had, you know,
Y2K like dates baked into our systems.
They were all system rules that were never really defined or
explicit as business rules. And if they were then the
business, of course, our leadership team would go, what
do you, what do you mean our system can't go past the year
2000? Sorry, that's definitely not a
business rule. That might be a system problem
that we have inherited because it's, you know, bad code or
someone's baked it in or equally, what do you mean we
can't change the GST VAT right from 15 to 17% without giving
$1,000,000 to SAP to do a change program?
So in summary, business rules are from the business, they come
from your stakeholders, they come from the owner of the
system or product or area in which you are managing the
business owner. So if you're not in a project
form, you know, like you have A and you don't have a product
owner, that's your business owner.
You define them in a list. When you are defining
requirements in that change space, in those process change
spaces, your scope, you would define them and review them as
part of your requirements. And they should be under your
user stories. That's probably the easiest way
to do it. But I'd also have them in a
defined list. They should be reviewed often
and they should be written in a business, easy to understand why
in business terms, and they should be really clear and
concise. And if they're complex, then you
may need to reference, you know, an article or a piece of
legislation to explain why the statement exists.
And yes, it's your job as ABA to do these.
Actually, it's somewhere where B as can shine.
Just like process modelling. Business rules are also an area
where the BA, the B and BA comes out on top.
I'll see you next week.