BPM: It’s About Managing Change (Fourth in a Series) - Rules, Rules, Everywhere Rules....

So, from even the list of examples in my previous post, it would appear that rules are everywhere in a business, and this is in fact a testament to the value of managing business rules effectively. For the most part, though, they can be categorized in relation to how they impact the other two main components of information systems: data and process.

For your data needs, business rules help with conditional relationships and data values. Consider the example of when an order qualifies for a discount. When an information system is used to create a new order, the database schema would have informed the programmer that certain data attributes are needed to create a complete and correct order — like item and discount — and what values those data attributes are allowed to be for the order to be considered valid for the business. However, a database schema cannot document and enforce rules about values of a field that are dependent on the values of other fields; those are rules. Further, if an order needs to have an association with a credit authorization when payment is by credit card, that is a conditional data relationship that cannot be described in a database schema; it is a rule.

For your process needs, business rules are critical for the decisions made in a process. Basic implementations of a BPMS will automate the flow of activities but will stop executing and exit to a user prompt when it reaches a decision point, the diamond in the diagram. A person needs to respond to the prompt and indicate which path the process should follow next. This is better than not having a BPMS, but it is not yet an ideal implementation.

Why? Consider that most decisions made in a business are consistent and ongoing applications of rules (e.g., does the customer qualify for a discount on this order?) and are made many, many times a day. In these situations, the person is looking up the rules in a manual or, worse, applying them from memory, which we all know can be faulty in even the best people. This is where BRM has its biggest impact. It can elicit those common rules out of the manuals and memories and get them into a BRMS, and then business processes will flow uninterrupted until a new situation arises. That is when a person is really needed, and once the new situation is understood, it too can be defined as a rule and added to the BRMS.

Next Time: A Model for Business Operations - Process , Data and Rules

BPM: It’s About Managing Change (Third in a Series) -Supporting Business Rules; will Brute Force work?

"....systems that implemented the data edits in program code were subject to even more requests for change, along with the requests to change processes; thus the backlog started to grow seemingly exponentially."
 
Many organizations tried to solve this problem with brute force: adding more resources, running more projects, outsourcing what could not be done internally. Other (fewer) organizations saw the diminishing returns that approach produced and started evaluating the problem laterally. They determined that data definition and then process definition captured a lot of what business is about, and automating their management was of benefit, but neither included "the set of rules that determine how a business operates — that is, rules that prevent, cause, or suggest things to happen." ("Defining Business Rules — What Are They Really? Final Report, Revision 1.3." Business Rules Group, July 2000)

These organizations realized that just as data needed a DBMS, and process needed a BPMS, business rules need business rules management (BRM) and a system to support it: a BRMS. I’m not talking about codelike procedures; these are human-readable rules that can also be implemented as declarative statements, such as:

- A customer can place an order, only if they are 18 years or older.
-A customer can place an order on credit, only if their credit rating is "good" or "excellent."
-The insurance coverage for a 10-year term life insurance policy must be $50,000 or higher.
- Premiums paid by direct debit must have a monthly payment frequency.
- A credit application greater than $1,000,000 must be approved by the manager of underwriting.
-An order is fulfilled, only if the ordered items are in stock.

As declarative statements, business rules need to be automated irrespective of any procedural order. All rules are applicable to the business at any time, not according to any order specified in a coded program. The structure of the rule statements must meet the two primary needs: readability and execution. The means of accomplishing this, fortunately, have already been developed and standardized for us through the OMG and its "Semantics of Business Vocabulary and BusinessRules (SBVR), Version 1.0.". The above examples meet the requirements of this standard and would be executable by any BRMS that supports it; so now your rules are don't have to be frozen in code.

Next time: Rules, Rules, Everywhere Rules....

BPM: It’s About Managing Change (Second in a Series) - Things change, but are they really different?

We can agree that business processes change a lot, but a little analysis of the nature of these changes reveals that they are of the same type(s): activities are added or removed, or the order of the activities is rearranged, or the criteria used to make decisions changes. This is what business process management systems (BPMSs) were created for: defining activities, decisions, and their order in a business process, with the ability to change the process in common ways without requiring an IT project. The power of a BPMS stems from identifying these stable patterns of change and supporting them with structures — activities, decisions, and the definition of their order — that allow for change.

THE DATABASE ANALOGY

To illustrate the point of stable change, consider database management systems (DBMSs) as an analogy. A database embodies a model/structure of an organization’s ongoing data needs, patterns of entities/objects, and their relationships — what database analysts know as the "schema." With this stable structure, new occurrences of data are added as needed through application systems; the need to add new data item definitions to a database is very infrequent, occurring only if the business of the organization changes significantly or the organization enters a new business.

Further, databases are not just containers; they are rule enforcers.The optionality and cardinality defined for relationships are rules, such as "an order must have at least one item being ordered but can have many items being ordered as well." This is what any business person will tell you is true about an order, so a database can be used to enforce these rules.

This enforcement is good, but it is also limited. Database rules, especially optionality, are cut and dried; they cannot implement conditional situations, such as "a relationship is mandatory only when x=y." For example, an order must be related to a credit approval if the payment method is credit card. When the business presented this kind of situation to IT, the data edit was born. As you might expect by this point, this response was implemented in code and used primarily when a new occurrence of something, such as an order, is created by an application system. It has also been known as the input edit, the screen edit, and the field edit. A special case is the cross-edit, where the value of one data attribute is constrained by the values of another. For example, a discount for an order can be greater than 25% only if a certain type of item is ordered.

This solution using code has caused even more problems than the examples described previously, because "data edits" are a technical IT term for business rules, and what I have learned is that business rules change even more often than the business processes that use them for guidance. Working in insurance, and then lending, I have often seen code that implemented underwriting business rules to automate decision making, only to then see the business rules change enough that the results produced by the code were no longer valid and had to be extended by manual workarounds. So the systems that implemented the data edits in program code were subject to even more requests for change, along with the requests to change processes; thus the backlog started to grow seemingly exponentially.

Next Time: Supporting Business Rules; will Brute Force work?

BPM: It's About Managing Change (First in a Series) - Why are Business Processes frozen?

Despite many things written and said about businessprocess management (BPM), it is really one thing for certain: an automation improvement that supports change management.

WHY ARE BUSINESS PROCESSES FROZEN?

Business processes are the lifeblood of an enterprise, moving and shifting to respond to the ever-changing business environment. They are sets of activities in an organization that are performed in response to a trigger— an external stimulus, an internal state change, a point in time that has been reached — to provide a desired result in response to that trigger.

The nature of business processes lends itself to diagramming them in some manner. You can present the starting and end points as circles, all the activities as boxes, decision points as diamond shapes, with arrowed lines connecting all of the above (swim lanes optional). What all this drawing means is that, given sufficient effort, it is possible to fully define a process as it exists at a point in time.

Why the emphasis on a point in time? Consider how most businesses’ processes and activities were automated for the first time: the process was defined, and programmers designed and coded programs for a system that executes the activities. On the day the system is implemented, and for some period of time afterward, it does what it was designed to do, and the business performs its processes using that system. No one is aware that the business process is now frozen in time.

Fairly soon, however, the business decides to change its process somewhat to deal with new problems or opportunities. The system does not support this changed process, so a project is needed to open the system, make the changes (correctly), test the changes, and implement the new programs for the system. This takes time. The business process essentially must be thawed out, redirected, and then refrozen.

By the time this effort is completed, however, the business has more changes lined up. Here we see the arrival of the two curses of information systems: (1) the backlog, and (2) the workaround.

Next time: Things change, but are they really different?

I am ranting about Agile again...

...and I am not proud of myself. A couple of years ago I worked myself to a space where if it worked for you, what ever method you liked, my feeling was "power to you". Even among Agile proponents there were some reasonable voices who decried the prevailing "If it isn't Agile, it's Crap!" hysteria.

But I obviously keep tuned to writings and postings about Business Analysis and Requirements, and some of the stuff that used to annoy me is seeping back into the mainstream, basically that "we have to do all this hard Agile stuff because you can never get good requirements before you start coding."

A lot of it is couched in seemingly sincere attempts to find a place in Agile, in Scrum particularly, for that poor soul, the Business Analyst. Even actually sincere attempts to do this carry the implied the subtext that "we have to find something for the BA to do, because he could never manage to do what he was supposed to do, get the requirements done first.... we would not want to see him/her lose their job..." So, let's make him the Product Manager, especially since the real business product manager can't be bothered to get involved. (Corollary note: i see all the time that developers want to work more directly with business users, but I can't say as I see business users saying the same thing about developers.)

So, I try ignore this and carry on, but then I end up commenting on posts like
http://www.batimes.com/articles/the-business-analyst-facilitator-role-in-an-agile-software-development-team.html

Maybe things will calm down again and some moderation will prevail... I hope so.

Cutter IT Journal: my article on BPM

Hi all,

Have a look at http://www.cutter.com/offers/bpmalternative.html to see the May issue of the Cutter IT Journal, with my article on BPM leading off.

Another attempt to understand Business Analysts

I am sure Ann Hall over at itbusinessedge.com is a nice person, and I appreciate her interest in what Business Analysts are or do, but she is not helping by quoting people who say my real key skill is customer service... have a look at http://www.itbusinessedge.com/cm/blogs/all/does-a-business-analysts-background-matter/?cs=41432#cf

Conversations

Linked In is a pretty good place for conversations these days, here is one on "Should the BA be a SME?" at http://bit.ly/9VhruQ (No fair guessing my view before reading it...)

Blogger's Block

I seem to be posting less often these days. and if no one else has coined the term, I will call it "Blogger's Block."

I have said before that when blogging first appeared, I paid it no mind as it seemed that they were all (mostly young) people's public diaries; eventually I saw that there were more and more blogs that were about topics of interest, the main ones for me being work-related on business analysis and methodologies and such. One of these must have been on blogger.com, which basically said I could have a blog too, just sign up...so I did. This was about the same time that after attending BA and IT conferences for many years, I realized I had things to say that were just as meaningful as the speakers whose sessions I was attending.

So, the dam was busted, and looking back, I am a bit amazed at just how much I wanted to communicate to anyone who might stumble upon this site. Often it was things I wanted to say in my work environment, but couldn't because my boss would not have liked it or it would have just fallen on deaf ears.

So over 20 years of thoughts and experiences just came pouring out, but the well is drying up. Perhaps it may be that what I am doing now as a consultant lets me speak more freely, along with the fact that I really like what I do now.

So, what to do about this? anything? does it matter? Should I start the "Best of David Wright's Business Analysis Blog", essentially re-run old posts that might still be relevant? or just let it fade away, it's purpose having been served? Stay tuned, anything could happen...

Agile is Fragile

Recent experience at a client showed me that Agile can be successful for a project, but maintaining a level of success across projects and organizations is difficult.The client had one team using Scrum that was delivering sucessfully, but several others that were not.

A manager of one of these other teams told me that their biggest problem was turnover in the Product Owner role; a business person would take on the role, get better and betterat it, then change jobs. The team would have to acquire a new person and start from scratch again.
The other most common problems were scope creep, and excessive change during dev sprints in a project. To me, these are another sign that the Product Owner role was not being performed well. Overall, the discipline needed to make Scrum effective was not being practiced.

The client's response to these problems was to focus on a process for requirements definition, to have stable and clear requirements available for use by a dev team, irrespective of the development process that team may use. Yes, this can be seen as a step backward from an Agile point of view, but what else could the client do?

As a consultant involved in implementing the new requirements process, I have to acknowledge that some readers would say I am biased against Agile/Scrum. What I am biased against is any process that is not working. The client's original use of Scrum is certainly before my time, but it can be safe to assume that it was done for good reasons, one of them likely being that up-front requirements was not working for them.

Over time, the above agile fragilities became apparent and something needed to be done. Rather than try to improve their use of Scrum, the client looked back to its original problems and determined that ifScrum did not solve their requirements problems, what else might? ...leading to me coming to this client to do a Requirements Process Improvement program.

That does leave the one team that is successful with Scrum; how can a Requirements Process fit into what they do? What their team leader and I have worked out together is that functional requirement statements (e.g. The system must have the ability to create an Order) can be matched to User Stories. A good set of Requirements helps deffne a much better and stable Product Backlog to use going forward with Scrum.

In the end, it is about the process, whatever it is, that works for an organization, delivers successful results, is repeatable, and can be learned by others with the same results; anything else causes more problems than it solves.

A Year on Twitter

I was a late-comer to twitter, one of the horde that joined in 2009. I was in a similar fashion a late-comer to blogs. When blogging started picking up, it was mostly painted as individuals exposing the equivalent of personal diary entries to the whole world. This was not something I had any interest in, but it eventually became apparent that people were blogging about topics of interest, including business and systems and methods and so on. Many of these people were authors of note on topics of direct interest to me. After seeing some of these, and realizing how easy it was, I started this very blog. It may or may not have have reached an audience of any size or import, but I have enjoyed it as an outlet for my thoughts and opinions on Business Analysis.

Then came Twitter, also first painted as people's random thoughts or status, the famous "what I just had for lunch" type of tweets; as before,this did not interest me. Then at the beginning of 2009, I saw some articles (and probably blog posts!) about how this odd Twitter thing might actually be useful, to busineses for example. I also saw on blogs I read the appearance of "follow me on Twitter" announcements. So I joined and started following some of these people. I have a been long-time user of Google Alerts to find things of interest to me, but I found I was getting links to things from Twitter that Google didn't pick up. It is apparent that following someone because of one interest may lead to other unexpected content. This is what I have found Twitter most useful for. People will tweet when they have a new blog post, and then tweet links to other things of interest.

I then discovered all the Twitter apps that tell you how influential you are and such. One thing they usually consider is if you are engaging with other tweeters in conversations, as opposed to just tweeting your own stuff all the time. I would say that of about the 300 people I follow, I do have conversations with about a dozen or so people, mainly other BAs and Systems folks.

The interesting thing is when you have a (probably one time) conversation with a more famous person. They may be tweet somethinng or even ask a question, which spurs me to reply. Most times the replies are not returned, but once in a while they are, which is oddly gratifying; recent folks I have conversed with are comedienne Elayne Boosler, and Peter Travers, movie critic at Rolling Stone. Why does this seem special? I guess it is like getting 15 seconds of fame (a whole 15 minutes of fame being so 20th century).

After a year, I guess what may be most surprising to me is that I have acquired over 500 followers... I mean, I think I have some interesting or funny things to say on occasion, and I do my share of re-tweeting, and I do tweet when I posted on this blog, or over at ITWorld Canada. Yet it does astound me that this has led to me to slowly but surely getting more and more followers. I don't expect I will ever have thousands and thousands, but actually getting into the hundreds was something I wasn't expecting a year ago.

Sure, I have used various apps to analyze who is following me. It is true that many are automated follows, like when I tweeted about the Toronto Blue Jays one day, their twitter account started following me. Then their is always the occasional email about a new follower who turns out to have been suspended for "suspicious activity". But there are some people following me I just don't understand, like all those people who describe themselves as on-line marketing experts.

However, there remains a group of people that number in the hundreds who found me somehow and decided "yeah, I will follow this guy." So, if you fair reader are one of those people, thanks a lot.

Great product for requirements sessions, why is it so hard to find?

The product is whiteboard sheets. They come on a roll, you rip one off and stick it to almost any wall surface, and it clings. You then write on it like a whiteboard, then the ink will dry permanently after a few minutes.

I and my peers use them in requirements discovery sessions. The walls fill up over time, so you can look at anything you have produced. The fact that the ink dries allows you to take them away and use them later for writing up results, and to keep as a record.

These are not a common item. Each new client we work with invariably says they have never seen them before. Our organization gets them from a supplier in Germany, the product packaging says Leitz.

Office Depot shows up as a source when you do a web search, and Amazon too, but actually finding them on their sites is difficult. Right now Amazon says they don't have any and don't know when they will.

If you look for them, don't confuse them with "instant whiteboards"; these are thick sheets that cling to a wall, but are erasable at any time, like a hard whiteboard.

But finding them is worth the effort, and I hope more people using them will make them easier to find.

Shoud use cases specify system solution?

Another new discussion : Shoud use cases specify system solution? Always good to make sure what seems obvious to us is clear to others.

Discussion: What do we do about IT Project Requirements problems

A discussion from the IIBA group on linkedin...

http://bit.ly/crfhTr

Deep in many discussions.... 10 Signs that you're really "Wagile"

I have not posted here much lately because I have been out there engaging in discussions on business analysis and requirements topics at various sites.

So, here is the link to a good one called "10 Signs that you're really "Wagile""

at http://bit.ly/aIWBmB

(I am not sure when I post this if the link will be usable, but a search on the topic should find it...)

Thoughts on Consulting #3 - you get access

Sort of a corollary to #2... When I am engaged to work with a client, all of their people you need involved tend to show up when you need them. Sure, I represent a specific expense that no one wants to be seen as wasting, but it can be more that. The seniority level of the people is high as well, so you know if you need a decision made, the decision maker is in the room, no one has to go off to get that decision from someone else.

I am not saying this is fair or anything, it's just the way it is, so I enjoy it as it comes.

Thoughts on Consulting #2 - if the Consultant says it, it must be right...

Thirty years in IT, 28 not as a consultant.

If you work in IT at a typical company, you may have had some good ideas, some recommendations, but they were not given their due by management, and you wondered what it would take to make some meaningful change... then an outside consultant comes in, and says basically the same thing, and management pays attention and says "that's great, let's do that!", and you sit there saying "but that's what I said...", or you keep your peace and help to make the change.

That's just the way things go sometimes, I have no great insight to offer you on this. Management laid out large amounts of money to get the consultant to come in, so it is real hard for them to say "we knew that already" or even "that sounds familiar...".

So, have I been part of something like this since I became a consultant? As Mr Bean said in in his movie "...not that I am aware of." I would like to think I would recognize it when I meet those employees, and try to work with them to increase the chances of success. So far, I have met people who agree on what the problem is I have come on to address, and want to help, but have not seen a case where someone already had figured out the solution before and had been ignored. The thing is, that could actually be true but I may never know it. So, I can only do the best job I can and leave everyone as happy as I can make them.

And if you are are an employee with good ideas not getting their due, maybe its time to start consulting!

Thoughts on being a consultant...

Since 1979, I was a regular IT employee of the organizations I joined and left up until early 2008. “Consulting” to others in the organization was something I started doing as I gained useful knowledge and experience (while trying to dump anything un-useful on an on-going basis…like Data Flow Diagrams), often within a staff unit that did R&D. I drove the implementation of new methodologies at one company, for example, to the point of defining and delivering training to other employees.

Of course, I also worked with external consultants now and then; most often they were people with experience in a method or tool the company was adopting, to accelerate that adoption. It is a slightly unusual that I never worked with out-sourced resources over those years; the employer I spent the most time with had been an early example of outsourcing their computer operations to a subsidiary, and then selling the excess capacity to other companies. But, the project and development staff stayed within the main IT organization to be ‘with the business’ and that included me. (This does not include the many contractors I knew who came on-site to work; to me they were peers who just had a different employment model.)

Back when outsourcing got going, it was all about the impact on programmers and related tech roles. As a Business Analyst, I was comforted by the initial assertions by various gurus and pundits that Business Analysts could never be out-sourced, because we need to be near the business people to do our jobs.

However, as I gained experience, learned a lot and (hopefully) got better at what I do, it became apparent to me that while Business Analysis could not be outsourced to other continents, it is a discipline that could be done by external resources. They would come in for a focused period of analysis and deliver a set of requirements that could indeed be understood by the business and be of use as input to design and development. I knew this because even as an employee, because more and more I would do analysis for one project, then move on to the next one while the first project moved into development. I would be available to that development team as needed for questions or changes, but this only required a small part of my time. So, it was not necessary for a Business Analyst to stay with a project until its conclusion, there was no more Business Analysis to do to keep them fully engaged. (Now, if a BA also manages the project, or does testing, that’s a different thing, and I avoided both of those tasks most of the time.)

Being somewhat of an optimist, I thought this could be an opportunity rather than a threat, and I started looking at consulting companies as an option for a career change. This ‘looking’ lasted a while, as the majority of consulting companies did not do business analysis; lots of design and coding, but no analysis. I did not want to branch out as an independent consultant, or even a straight contractor, a little too risky.

However, I and the right consulting company found each other in 2008. It took only a few weeks before I joined up.

Hmmm, this has been a lot of lead-up to what my thoughts are now; perhaps they will help someone else who is heading down the same path as I was.

So, thought #1, concerning Travel: the typical week is fly out to a client’s location on Sunday evening, work 5 days, return home Friday evening. I had never minded doing business travel in the past, but it was not frequent, so the concern is what will traveling all the time do to you; will you burn out in some way?

Two years in, the travel is OK. It’s not glamorous; all I see is airports, hotels and client offices. Only one time have I stayed over at the client location to do a little sightseeing; that is not the same as a vacation with family, though, so I don’t expect to do it again soon.

Speaking of family, I have three sons, and the youngest was 20 when I started this. I don’t think this could have worked when they were growing up, it would not have been fair to them or their mother, so the timing has worked out.

Benefits? A lot of hotel points that did cover lodging for our last vacation. Most of my flying is short-haul on the east coast, so the frequent flier points are building slowly. Don’t believe I will reach the million mile level anytime soon…

More thoughts to come in future posts….