!Process Cafe Process Cafe

Showing posts with label Business Rules. Show all posts
Showing posts with label Business Rules. Show all posts

Process inconsistencies hit the customer... Again.

I rented a van last week. Just a standard Luton van. I used it for transporting some set pieces to the performance venue for a local group I am a member of.

When I went to the rental location I took my drivers license and the associated 'paper documentation' which is issued by the UK DVLA. This details all the endorsements "points" you have as well as your entitlements to drive (Motorcycle, Heavy good vehicle etc.)

I've rented vans from this location before and they have my details on file so I filled out the form, signed on the line gave them my credit card and went. The guy didn't ask to see my license or paper documentation but did ask if I had any endorsements since my last visit (which I hadn't).

This week I had to rent a van again now that the production has finished. I asked a colleague of mine to drive me to the rental location. At the desk the woman asked me for my driving license (Which I supplied) and for the paper documentation. I told her she didn't need it as the last time I rented a van I hadn't needed it and all my details were on file. She insisted that I needed to produce the paper documentation. I told her I hadn't brought it because last time I brought it to this same location I hadn't been asked for it.

She insisted that she needed to see the paper documentation before she could rent the van to me. I told her that I didn't have it with me and she would have to phone the DVLA to get the authorisation (This is a 'fall-back' process which has been put in place for just such a situation)

"It's Sunday" she said. "The DVLA isn't open"

So, in other words, because she is following a different implementation of a standard process, I would have to schlep myself back home (with my colleague who had dragged himself out of bed early on a Sunday morning) just to get a piece of paper which I had told her was all in order and wouldn't need to be checked when she got it.

Stifling the urge to strangle her (or at the very least to use harsh language) I went back and got the documentation and the deal was done.

But it got me thinking. Where did the process break down? I had taken the right documentation last week but hadn't been asked for it. Obviously it wasn't needed as part of the process otherwise I wouldn't have been able to take the rental van. If this was my first time renting with them then this would have been different, but because they had my details on file the process was modified. If a licence had been needed to rent a van the process would have stopped me from taking the van away when it wasn't presented, like a credit card. A credit card was needed to rent the van. If I hadn't taken a credit card then I wouldn't have been able to rent the van. Therefore the credit card was needed, but the license wasn't. It might have been desired, but it wasn't needed.  If it wasn't needed, then I shouldn't have had to schlep back home to pick up the documentation this week.

If, on the other hand, the first guy had made a mistake and let me take the van without seeing the licence - despite the fact that it was needed - then their internal process is broken to such an extent that a major check such as this was bypassed. Either way this company has a problem.

As a customer the aim of the company should have been to make my interaction with them as painless and as rewarding as possible - especially in a service industry. But this company obviously doesn't work that way. To quote the BPM guru's on the web 'The company doesn't use 'outside-in' thinking". It's one of the process maxims: 'Keep it as simple as possible'. Having my details on file was meant to keep things simple. Requiring me to produce additional documentation was complicating things when it wasn't needed.

Should I avail myself of their services the next time I rent a van, or should I go elsewhere?

Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this book.


All information is Copyright (C) G Comerford



The Hole in the system

MRP vs. ERP — Manufacturing management systems...Image via Wikipedia

One of the things that people are very prone to do with processes is to leave some sort of a 'hole' in the system.

I was reading one of the multitude of blogs I read daily when I came upon an excellent post from Havi Brooks at The Fluent Self. In this post Havi was talking about 'The hole in the system'.

Basically, she explains, most people define 'systems' around themselves but leave some sort of a hole in there which causes problems later on.

Specifically she gives 3 examples:

1) "The baby-bathwater thing": Which is where systems are in place but are subverted because of some emergency situation
2) "The misguided assumption thing": Which is where systems are bypassed based on assumptions that would not have been made had the system been followed
3) "The 'not allowing for stuff going wrong' thing". Where systems only account for the ideal situation to occur and are not designed to cope with occurrences where things don't happen as designed.

What struck me about the post (and the three examples quoted) is that they are pretty universal - especially when applied to business processes. When I look at processes in place in business today they tend to be designed from the point of view of 'this is what should happen' rather than 'this is what can happen' it's a subtle difference, but very important.

There are, of course, whole industries that have sprung up to deal with the different scenarios detailed above - things like decision management systems for example. But am I the only one who thinks that it might be a good idea to design your systems correctly in the first place? How many times have people fallen into the trap of designing a business process - for example - to match a specific piece of software functionality but then suffered when that software can't cope with a customer who comes in with an emergency (The 'baby-bathwater thing')? It happens all too often. This is not to denigrate business decisons systems at all, but merely to look at specific probems through a different prism.

I am a firm believer that processes should be designed to be tool independent. That way when you change your underlying ERP or CRM system (for example) you don't actually need to redesign your processes. Havi says:

It seems to me as though most challenges that tend to come up in these situations have two sources.

Maybe the system is flawed. There’s a spot where things get stuck, jammed, or fall through and get lost. Or a great system is already in place, but we’re just not using it. Which is the flaw.

Fundamentally Havi is speaking of the two bugbears that dog any system's implementation: Putting in a system that works but isn't used correctly or putting in a system that doesn't work correctly.

So how do we solve these two problems?

I would say we don't.

Or, more particularly, we can't. It is fundamental in human nature that we seek the easiest solution. Generally the easiest solution is that which needs the least amount of work, or that which produces the ideal result the quickest. This can be the kind of thinking that produces systems that don't work correctly. Alternatively we can spend time, money and effort in creating virtually foolproof systems only to then have the users bypass these systems when an 'emergency' arises. But let's also look at the opposite side of that equation. How many time have you rung the bank, or some other 'call centre' system and asked them to do something only to be told that 'the system won't let us do that'? This is an example of a system that has been designed to work in one way but which we now want to subvert by not following the process. The well designed system has had safeguards built in that will not allow you to do anything like this. But at the end of the day you end up as a dissatisified customer. So is the system working correctly?

Yes it is. It is working absolutely as designed. But is it working in the best way for the customer?

I don't think so.

Perhaps the solution is to make systems more flexible? Maybe we need to try and ensure that users can perform the tasks they wish (regardless of what those tasks are) and then manage the fall-out using something such as decisions or rules based systems. But somehow I can't help feeling that this is tantamount to creating another 'hole in the system'

Thanks to Havi for the original post.



Why processes can't be 'stalked and captured'

Forbes.com has an article that is garnering some attention around the web. it's called "Stalking and Capturing a Business process" and it is concerned with how we design a business process. As the article says:

Why are business processes seen as being handed down from on high? This week, the JargonSpy argues that business processes are like wild animals. They should be stalked, crept up on and then captured.

It goes on to mention several methods of doing this. These include Wiki-Based process discovery, Task-based process discovery and Mash-up-based process discovery.

The problem I have with all these approaches is that they are fundamentally flawed in their underlying principal. The article is predicated around the fact that new business processes come down 'from on high' with minimal, if any interference from the users. This is flawed for two reasons

1) Processes do not come down 'from on-high'. Good process design is a combination of interview, facilitation and process discovery

2) Asking the users to design the process using wikis, mash-up's and task-based discovery is tantamount to asking the fox to design the chicken-coop. Users do not know the best process to do their work. They know the current process, they may even know some flaws in the current process, but they don't have an overall view of the end-to-end process and they certainly don't know how to design the process to work correctly with, for example, a new system that may impose restrictions on how their workflow operates. Many users, in fact, do not even understand the difference between a business process and a procedure (but then again not many process analysts and industry experts do either). Getting them to define and document their own processes is not a viable proposition.

The key issues is that users are users and process analysts are process analysts. It is the role of the process analyst to determine what happens at the moment (using facilitated sessions, questionnaires and observation) and it is the role of the user to validate and confirm that. Of course the analysts should work in tandem with the user and of course the process must be defined whilst understanding the users needs and requirements, but the skill of the process analyst (The good one anyway) is in putting together a process which meets those requirements as well as giving them something they don't already have: simplicity and easy of use.

Stalking and capturing your process will result in a caged wild animal. You don't want one of those running your business, do you?

I do agree with the following point made in the article:

Fred Brooks, author of The Mythical Man Month, teaches us to plan to learn from the process of building the first version of asystem, and then throw it away and build a second one that has a better chance of working. Advocates of agile and extreme programming tell us to build the smallest possible system and put it in the hands of users to get evidence of what really is needed. Then keep this loop going and
improve the system rapidly. Google has led the way in launching large-scale products advertised as beta versions, a moniker that sets the expectation that continual evolution will take place. This is the triumph of incrementalism.

I am also aware enough to understand that in big business process improvement projects working in this iterative or waterfall method might not be allowed.

We can always hope, though.



Is Starbucks missing a trick?



I read with interest the latest news from Starbucks:

From Bloomberg: Starbucks Corp., the world’s largest coffee chain, will stop continuously brewing decaffeinated coffee after noon as part of a drive to waste less and save $400 million by September.

The company, which last year started brewing fresh pots of coffee every 30 minutes, will have the caffeine-free version available upon request after 12 p.m., the Seattle-based company said today in an e-mailed statement. It takes about four minutes for a fresh cup to brew, spokeswoman Bridget Baker said.

“For many of our stores, the demand for decaf is greatly reduced in the afternoon,” the company said in the statement. “With our current standard of continually brewing decaf after 12 p.m. regardless of demand, we have seen a high amount of waste.”

So there you are. Apparently decaf coffee is not needed as much after lunch. Who would have thought that?

Actually looking at this from an efficiency point of view this is a very good move. They are not removing decaf totally, just reducing waste through not brewing and disposing of coffee that isn't being sold.

In today's economic hard times this makes a lot of sense. It reduces waste, decreases cost and doesn't reduce customer satisfaction. Although you do have to ask the question of why they don't brew to demand for everything? I visit Costa coffee and Cafe Nero (both far superior to Starbucks) and when I ask for decaf it get's brewed on the spot instantly - but then again so does the non-decaf stuff. In fact nothing is brewed on a cycle, it's all to order.

Does this mean that Starbucks are continually running 'freshly brewed' coffee (which could be as old as 30 minutes) throughout the day? Why are they doing this? What is the process point?

This obviously produces waste ($400 million in 9 months - WOW!) produces coffee which is old and stale and doesn't provide the same level of service as sites such as Costa and Cafe Nero. So why do they do it? Is it to get more people through the door quicker? Maye. But doesn't this cause an issue with the number of people that can physically be accommodated? A lot of people who are there will probably be sitting with a laptop availing themselves of the Wifi, so there is a theoretical maximum amount of people that can go through in a given length of time. Obviously take-out's will increase this number, but how many people come into Starbucks just for a 'coffee?' Don't they ask for a'double decaf vente grande skinny with whipped cream and 6 sugars'?

Without evidence to the contrary I think Starbucks have missed a big opportunity here. What do you think?



Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this book.



For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Business process in health care - How surgery became a business process.

If I say 'Business process in health care" I would presume a lot of you would think I was referring to its application within Health Insurance. Right?

But what if I told you an organisation in the US is looking seriously at implementing business process management.. for surgery. That's right, they are looking at how following fixed surgical checklist procedures can eliminate or at least decrease complications and increase recovery rates. This will have a corresponding positive effect on health care payments and therefore reduce premiums.

Geisinger Health Systems in Pennsylvania runs 3 hospitals with a fixed (i.e fairly predictable and constant) patient base. This made it possible to look at this sort of process.

The premise was very simple: Statistically it is known that different surgeons perform different operations in different ways. If operations could be standardised this would remove variations and herefore eliminate unknowns as a result of this.

The hospital chose coronary-artery bypass graft (CABG, pronounced cabbage) surgery as a test-bed. It appears that there are 40 different steps that need to be aken to make this a succesful operation and in 55% of cases the New England Medical Journal found that all necessary steps were not being taken in surgeries. Putting these two figures together the cardiothorasic surgeons at Geisinger formulated a list (process) of steps that needed to always be performed. Surgeons were bonused on their ability to stick with the list (unless they could identify and document why a step was not necessary in a particular case) As a result costs are down 5% and - more importantly - there has been a 45% decrease in re-admission rates and a 60% decrease in neurologic complications. Both of these figures has resulted in lower costs for the insurer.

What's important to note here is the approach that was taken. It is key to ensure all busines process work follows the same typical path.

  • The initiative was started by the key upper management - in this case the Geisinger CEO Glenn Steele. Thus there was good upper management buy-in
  • The process was defined by people who knew what they were doing. They didn't produce some arbitrary figure of 40 steps, they had their cardiothorasic surgeons analyse and define what the steps were - thus they had acceptance from the users
  • They had an incentive: Bonuses were based on following the process.
  • They had an exception process: Providing things are appropriately known and documented the surgeons had the option of ommitting a step from the process (In this case surgeons opted to skip a step in only three cases out of 181)
  • They measured the process. One of the surgeons involved in the process ended up having the cabbage surgey himself. The surgeon says the case opened his eyes to how complex a routine operation really is: "Two weeks after, the head of our IT group called
    me and said, 'Al, I just looked through [Steele's] chart, and I want to
    send you a list of everybody that accessed the medical record from the
    time he was seen in the clinic to two weeks post-op.' There were 113
    people listed -- and every one had an appropriate reason to be in that
    chart. It shocked all of us. We all knew this was a team sport, but to
    recognize it was that big a team, every one of whom is empowered to
    screw it up -- that makes me toss and turn in my sleep.
    " This is true measurement
As you work through your day-to-day business, are there any sections of your work which, traditionally, wouldn't have come under a BP pervue? Do you now think that this might be something you could look at? After all if open-heart surgery can be improved with business process management, surely something a little less life threatening can....

For more information and detail behind this read the Fast Company article Geisinger Health System's Plan to Fix America's Health Care


Business Process and Social media [...continued]

Following the previous post on 'Business Process and Social media - Good Bedfellows', I was somewhat disappointed at the lack of uptake in this topic.

It seems to me that there should be an opportunity to merge two key capabilities together to create something which is greater than the sum of the individual components. Perhaps now is the time to start looking at how we leverage social media in the organisation to make business process definition and implementation more streamlined and easier. This will reduce overhead, decrease costs and increase efficiency.

However of the various discussions that occurred around this topic the only one that was written as a comment on the previous post was from David Stephensen from Australia who said
I have to admit that Twitter seems like a bit of a stretch for doing actual projects unless your client is someone who naturally uses it (then it would be interesting).

I firstly want to use SN as yet another method of driving traffic to my site and getting a reputation as an expert, but that would apply to marketing any business.

I shall ponder this further as I play more with it.

When I think about it, it is true that the power of something like Twitter is in driving traffic (or at least having conversations) regarding various topics.

I'm more interested, though, in whether social media/social networking tools can be considered a tool in the process management arsenal. How can we leverage the power of a tool such as Twitter or Friendfeed/Plurk etc. to help better define and run our internal processes..?

People, obviously, are involved in business procedures - which I see as a lower level of detail to basic business processes - so their perspective on this would be very interesting.

Any further thoughts?



Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this book.



For more about me check out my "About Me' page

All information is copyright (C) G Comerford

Business Process and Social Media : Good bedfellows?



(Hopefully this will be the first of a series of posts regarding the interaction of social media with the world of business process).

Ken Evoy (CEO of Sitesell.com) has stated that he can't, yet, see a valid business case for using Twitter to promote your business. Or rather he has yet to see a valid case study where someone has successfully built their business using Twitter. Personally I'm not sure that's still the case. Hopefully someone will let me know if there is one out there.

But I want to be a little more parochial now and focus on business process and how the use of social media might help that in some way.

What is social media?
In this context when I am talking social media I am referring to applications on the web which enable social interaction between the great mass of internet users. Typical tools include Plurk, Twitter, Friendfeed, Facebook, Myspace etc. They all work on the basis of having a 'pool' of contacts or friends that you interact with on either a one-way or two-way basis. (On Twitter, for instance I follow about 70 people, but I am being followed by 3 dozen. What I try to do is make sure that the people who are following have a wide reach)

So: Business Process
Looking at business process and social media I can see at least 1 major interaction: The inclusion of some sort of social media interaction within a step of a process.

  • Use Twitter, for example to communicate the status of a piece of work
  • Use Friendfeed to review this status (especially using their new 'auto-refresh' functionality)
  • Use Twitpic to send a photograph or scan of a document to someone else for review

However this is effectively using SM as a substitute for Instant Messaging (or similar). In itself this is not using Social Media in the way that can provide the best value: as a mass communication vehicle.

I would be interested in other ways readers might feel that this could work. Is there an example you know where something like this is being done? Are you working on something similar already? What about items such as Facebook? Can that be part of a business process?

What other ways could the worlds of SM and BP interact to add value and reduce complexity?

Next Steps
As I said at the start I would like this to become a series of posts about Social Media and business process therefore if anyone would like to take this theme and post a further entry about their take on SM and BP I would be happy to host that entry here on the Process Cafe as a guest blog. Alternatively if you have similar posts already and want to link into them in the comments, please feel free to do so.

I look forward to an interactive and interesting discussion.



Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this book.



For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Flying - a complicated process?

In a recent post I talked about the linkage between golf and process. My contention was that good golf is process based to the point where measuring the appropriate item and focusing on improving the process around that item can reap dividends.

Now I want to expand on that by giving an example where this is not appropriate

Flying.

Last year I got my Private Pilot's Licence and I now spend as much time as I can afford in the 'wild blue yonder' learning as much as I can about the plane, navigation, Air Traffic Control, circuits, VP propellers etc. etc.

It struck me recently that flying is very much process based and usually it is when processes fail that aircraft accidents occur.

Let me give you an example: Most Controlled Flight Into Terrain (CFIT - basically a plane hitting a hill, mountain or rising ground) is a result of several factors: Tiredness, lack of concentration, spatial disorientation, flight into poor weather, lack of communication, wrong pressure settings on the altimeter and poor flight planning. Basically all of these can be solved through an appropriate process.


Tiredness: Business Rule"Don't fly on less than 8 hours sleep"
Lack of concentration: Process step "Follow appropriate check lists when operating"
Spatial Disorientation: Process Step "Follow Instrument readins to remove disorientation"
Flight into poor weather : Decision "Is weather bad? If yes then turn back or land immediately"
Lack of Communication : Process Step "Always contact ATC and keep them informed" plus 'Read back all clearances and permissions"
Wrong presure settings on Altimeter : Business Rule "Review Altimeter setting regularly and confirm setting with ATC"

This is, actually, a rather flippant approach to what is a very complex matter.

Flying is controlled by processes. Check lists, standards, licenses, ratings, reviews, evaluations etc. All of these things apply to pilots worldwide - from folks like me who have less than 100 hours experience on a single-engined plane right through to the guys with thousands of hours flying 747's across the globe. We are all subject to the same standards when it comes to flying.

All of these standards boil down to one thing: The correct way to operate a flying machine. In other words the process of flying. Every plane has a Pilots Operating Handbook (POH). The POH mandates performance envelopes for just about every factor regarding the plane itself: How much fuel it can carry, how much fuel it uses at what speed, how fast it can climb, how high it can climb, what is the best speed to glide the plane in at if there is an engine failure, what's the fastest speed this plane can fly without damaging the structural integrity. In the process world these parameters are either business rules or decision criteria.

Likewise, a pilot has a set of criteria to govern how he flies: Is he approved to fly this type of plane? If he is, can he fly in bad weather, or at night? Can he fly a plane with more than one engine? Can he fly a plane where the cockpit is primarily computer screens rather than the traditional dials?

Even before getting into the plane the pilot has a list of items that need to be carried out - the pre-flight checklist: How much fuel is in the tanks? Has the engine compartment been visually checked for oil leaks? Is the oil level in the engine between acceptable limits? Are the flying surfaces free to move? Is there damage on the leading edges? Do the wheel supports have sufficient travel in them? Are the pitot tubes blocked? Are all the radio aerials attached correctly. Do the flaps extend fully? Does the fuel pump work? Do the radio's work?

The list extends once the pilot gets into the cockpit: Are the dials functioning correctly? Are the circuit breakers set appropriately? Is the compass deviation card present and up to date? etc. etc. etc

Even when talking on the radio there is a set protocol to be followed (In fact you can't use a radio without having passed a specific exam and been granted a Radio Telephony Operators certificate).

All of these things work together to reduce the possibility of misunderstandings, omissions, errors and issues.

But of course problems still occur. So why is that?

Mainly, because there are human factors involved. A large proportion of aircraft accidents have an element of human error as the attribute. The worlds worst air crash (Which occurred between two 747's on the runway in Tenerife in 1974) was caused by a pilot hearing what he wanted to hear on a radio and not what was actually said. This was because he wanted to hear a take-off clearance rather than a delay. A delay would put the crew passed their flight window and result in them not getting back home that evening. He heard a take-off clearance and went, unaware that another 747 was taxying up the runway at that point. The two planes collided in fog resulting in 583 fatalities. At it's basic level this was a process failure because the pilot did not read back the correct clearance and this resulted in a communication error.

Let's come back to earth (so to speak) and talk about something a lot less drastic, but still as dangerous: Carb Icing. Without going into too much detail, propeller planes that are not fuel injected have a carburetor. The carb feeds high pressure air into the engine to allow it to work. however the mere fact that it is high pressure (it is forced into the engine through a constriction rather like putting your finger over part of the end of a hosepipe) means that certain physical forces come into play regarding temperature. The long and the short of it that under the right conditions (i.e when you have lots of moisture in the air and cold air in the carb - or example when you reduce engine power), a large lump of ice can form in your carb and stop your engine. Not what you want! To combat this, engines have a carb heater which can be turned on to remove the ice blocks. They generally work like a treat. However they can't be left on too long as they reduce the efficiency of the engine. Therefore there are key moments when you can add carb heat to be most effective.

The process says you add carb heat when reducing power on a warm day. The process says you add carb heat when making final checks for landing (although you don't keep it on). What the process doesn't say is that you add carb heat during taxying over wet grass on a cold day. However this is another occasion when ice can form.

So is the process wrong? No.

The 'rule' attached to the process says that carb heat should be applied 'whenever conditions for carb icing are present'. Training should indicate that any occasion which would allow moist air to enter the carb under conditions where the temperature is low should warrant carb heating. The problem is that the conditions for carb heating are not always known and understood.

Believe or not carb ice can form in an engine when the outside temperature is 20 degrees celcius. It can also form very quickly so action needs to be taken ASAP. I learned to fly in Florida with very high ambient temperatures, but was still taught to add carb heat at the appropriate time.

All this could lead us to think that even if the process works correctly there are always circumstances where things can fail. This is, of course, absolutely true. What happens when all the process and procedure is followed and there is a technical issue with the carb heater? Answer: The engine will probably starve through lack of oxygen, stop working and you will be forced to follow a different procedure that of an emergency landing.

"But isn't flying a skill rather than a process": I would maintain (in a similar way to my golf analogy of recently) that the skill comes in the application of the process to the best ends. Good pilots are those who have technically applied the process to a finite degree of skill. The guys who know exactly the correct approach path to bring a plane down at it's POH operating speed and bleed the airspeed off until it stalls right onto the ground without a bump or a jump. These are the guys who are following the process in exactly the right way. The pilots who drop the plane from a height after realising they are going to overshoot the runway, slam the wheels onto the tarmac, bounce (or 'porpoise') three or four times down the runway and then wear the brakes down trying to stop before reaching the end are the ones who haven't followed the process correctly.

Being a good pilot actually means being a skillful process follower!



For more about me check out my "About Me' page



All information is Copyright (C) G Comerford


Safety in the Skies

I've picked this up at a couple of places on the web and it's worth repeating.

A recent article at the BBC told the story of whistle-blower in Air Traffic Control who claimed that the controllers are deliberately sequencing aircraft closer than is necessary in order to meet targets for aircraft movements. He claims this is common-place and potentially impacts safety.

This is interesting for a couple of reasons.

1) From a process point of view, the process allows controllers leaway to do this sort of thing (apparently with the collusion of their management). Is this a process issue? Should there be stronger controls? Is the procedure designed well enough?
2) From a flying point of view, are we comfortable that the system can deal with aircraft being this close? I know that on several occasions flying in to Heathrow as a commercial passenger the aircraft has had to go-around because the plane in front hasn't vacated the runway yet. The go-around procedure is meant for just such an eventuality, but to need to do this due to air traffic issues is stretching a point, I feel.

So as a passenger would you rather arrive on time, but in a potentially risky situation, or later than advertised but safer? I know where my vote is going

Any thoughts or comments from you?



Some great posts from the Enterprise Decision Management Blog


I ran across the links below at the EDMBLOG where they had posted a link to 10 of the most popular stories and entries they made during 2007.

Some of these are really good and I recommend you check out the EDMBLOG whenever you can. If you don't have it on your RSS feed, you should!

  1. Business Intelligence 2.0 and Enterprise Decision Management
  2. Why are business rules better than traditional code?
  3. Windows Workflow Foundation - rule engines and rule management
  4. The secret of business user rule maintenance
  5. Customer Segmentation to increase profits
  6. Business Rules, Business Decisions, Intelligent Processes, Enterprise Decision Management
  7. Book Review: Competing on Analytics (the only book review to make the top 10, though Execution. The Discipline of Getting Things Done came close)
  8. What's the difference between Business Rules Management Systems and Business Rules Engines?
  9. Different Perspectives
  10. Using decisioning to build the bank of the future