Large companies rely on their Enterprise Resource Planning (ERP) and other supply chain systems to manufacture, distribute and manage the products their customers need. The behavior of these operational systems is critical to how a company treats, and is perceived by, its customers, its partners and its suppliers. Yet these systems are often plagued by manual interventions that delay processes, by hard to change constraints and thresholds and by problems with local exceptions to global processes. This session will show how using Decision Management to apply business rules and analytic technology can upgrade your ERP to be smarter and more agile. Illustrated with case studies, one attendee will receive a free signed copy "Applying Real-World BPM in an SAP Environment".
At its heart a decision is a choice, a selection of a course of action. A decision is arrived at after consideration and it ends uncertainty or dispute about something.Decisions are made only after considering various facts or pieces of information about the situation and participants.Decisions select from alternatives, typically to find the one most profitable or appropriate for an organization.Decisions result in an action being taken, not just knowledge being added to what’s knownThe basic decision making process is simple. Data is gathered on which to base the decision. Some analysis of this data is performed and rules derived from company policy, regulations, best practices and experience is applied. A course of action, a selection from the possible options, is then made so that it can be acted on. When considering decisions in operational business processes, the way the decision is made is often constrained such that it can be described and automated effectively in many, even most, cases.
As we are talking about decisions it is worth remembering that all decisions matter, as Peter Drucker noted. Not just the big, strategic decisions of your executives but the day to day decisions that drive your business.
Volume—Perhaps the most common characteristic of operational decision problems is that the number of decisions of a particular type you must make is high—so high you must automate it or high enough that many front-line workers must make it on your behalf. Volume alone can cause problems or exacerbate another decision problem, such as compliance or risk assessment. Latency—Many managers now have more timely information about their business. If you can use this information to see trouble coming but can’t change how you make decisions in time, you might have an operational decision problem. The latency between knowing something must change and being able to change it probably comes from having systems or people processes that are hard to change quickly. This is often caused by the way operational decisions are handled.Variability—Try imagining nightmare scenarios and thinking about what approach you might take. Think about the systems and people interacting with associates. Decisions those systems and people affect that must change to reflect your new approach could well be operational decisions that, although not a problem now, would cause problems if the business climate changed suddenly.Compliance—Ensuring that decisions are made consistently by using the same set of guidelines and policies and being able to prove to regulators that the correct rules are in place and used for a given decision can be difficult, especially if the decision must be made in any sort of volume. Demonstrating compliance in every operational decision can be particularly time-consuming if the decision isn’t automated correctly.Straight-through processing—“Straight-through processing” or “once and done” processing involves performing every step in a transaction or process without human intervention. A manual review that drags down response time in a process might be hiding a problem-prone operational decision. If you have a mostly automated process that hangs up on manual reviews, you might have a good candidate for an operational decision.Managing risk—A prime reason for having a person involved in a process is to manage risk, which is often all about making decisions that manage trade-offs or risks and rewards. A risk-centered decision that must be made quickly or in volume might be a good candidate for an operational decision.Unattended—With some transactions, there’s no choice but to automate a decision. Without automation, there’s no way to inject expertise or learn what works better and improve the decision; for example, there’s no person who can make a decision in transactions on your Web site or at your ATM. These kinds of decisions are often good candidates for operational decisions.Self-service—Complex decisions are more common in self-service. No longer is it enough for a self-service portal to deliver a document or ask someone to call an 800 number when things get complex. Now you need to automate this decision so that customers can self-serve, even when the decisions involved are complex.Personalized—Any time you want to personalize interactions with associates, you’re making a decision. For most organizations, these operational decisions can create problems because of the need to balance timeliness with personalization. (Taylor and Raden 2007)
much of a typical mainframe system is static, works fine and needs no maintenance. Often only a small portion of the system is responsible for much of the maintenance work. My suggestion would be to find the COBOL that represents business decisions such as a pricing engine (what price is this product for this customer), eligibility logic (is this customer eligible for this offer or service), approval rules (can this claim be auto-approved) and replace those parts of the application with Decision Services.
Remember – decisions are where the business, analytics and IT all come together
The consequences of this are 5 foldFirst we isolate decisions so that they can be managed and controlledThis allows the high-change, complex logic elements of legacy applications to be externalizedIt gives us points of control and agility in processesIt allows for the easy integration of analyticsMost of all, it puts the business in control of decisions even when those decisions are being automated and delivered into our applications.One of the interesting facts about Decision Management is that it was created by studying history and observing what worked – I know as I was there. This was not an attempt to describe a new thing but to give a label to an old thing – something that worked and worked well in a particular environment because it seemed that the things that had limited it to this niche – hardware cost, performance, software techniques – were a thing of the past.
People make decisions based on prior experience and expertise.People make decisions based on pre-conceptions and biases.People make decisions based on policies and regulations and their understanding of them.People make decisions based on historical information and their analysis of itPeople make decisions based on context
Here’s the stack again just to be clear.But #39 is important here too – managing readiness and organizational change.
So making decisions correctly will be hard unless we can pull all these rules together.Given this is how rules often look to start with, this is clearly going to be hard.But rules also change…Because your business policies doBecause your competitors doBecause the law doesBecause stock levels doBecause your services and products doBecause your customers doBecause your customers’ needs doSo we need something that will let us collect, manage and update the business rules that drive our decisions
Customer ChurnCustomer Service CallsLoss to CompetitorsRetention Budget
Let’s take a process like completing the sale of a subscription service, a location-dependent one like a cell phone, and see what decisions are part of that process. The process involves a customer specifying the service they want, answer questions about themselves and then either getting accepted or rejected.In this process there is clearly a decision – can this customer buy this service. We can drill into this a little. To determine if a customer is eligible for a service we might do several things. First we might check to see if the service they want is available in their area, we might check to see if we still have capacity on the service and then we will see if the information provided by the customer makes them eligible for the service. So now we have a decision with three rulesets or sub-decisions:Can this customer buy this service?Is the service available where the customer livesIs there capacity on this service?Is the customer eligible for the service?Interestingly we can immediately see that the first of these might be one we want to expose as an independent decision so that a customer can check to see if a service in which they are interested is available in their area. Similarly we might combine the first two for a customer service representative to answer a customer question. The difference here is that we might not want to expose problems with capacity too casually.Returning to our process we might decide that we don’t just want a yes/no we want what I call a “yes and/no but” decision. In other words we want to say yes when we can but also see if there is a cross-sell/up-sell that makes more sense. Similarly if we would have to say no we want to be able to say no but you can get this product (presumably something similar).Now we have a second decision – what is the best upsell/cross-sell for this service for this customer. This would take customer information and a service (one already approved for them) and return either a replacement service (an upsell) or an additional service (a cross sell). This decision probably has two sub-decisions:What is the best upsell/cross-sell for this customer when buying this service?Is there a replacement service that is a compelling upsell for this customer for this service?Is there a cross-sell/additional service for this customer when buying this service?And if the first one returns a new, upsell service then the cross-sell would need to be executed against the upsell service.And we have a third decision – what is a similar decision for this customer when rejected for this service. This too has two sub-decisions:what is a similar decision for this customer when rejected for this servicewhat services are similar to this service?which services (from a list) is this customer eligible for?Interesting the second sub-decision uses the same rules as the eligibility check mentioned earlier but takes a set of services to check not a single one. Also we might choose to expose the what services are similar decision as a decision so that a customer looking at a particular service would see a list of “other services you might want to consider).Finally we might decide that pricing is not static for these services and so add a decision what is the price for this service for this customer at this time? This could use things like promotions, customer profile and existing products/services owned to calculate a discount etc.
Transcript of "Importance of decisions OMG"
On the importance of decisions<br />James Taylor,<br />CEO<br />
Decisions and smarter systems<br />Different kinds of decisions<br />Introducing Decision Management<br />Business Rules and Decision Management<br />Analytics and Decision Management<br />Wrap and next steps<br />
Consequences of Decision Management<br />Business Control of Decisions<br />Simpler, more agileBusiness Processes<br />Integration of Business Analytics<br />Externalization from Legacy Applications<br />Separation of Decisions<br />