At the core of DecisionsFirst Modeler is the decision requirements diagram. These diagrams allow you to describe how, exactly, your organization wants to make a decision or currently does so. There is also a short demo.
From the home page, click on the Hamburger Menu and Select Create > Diagram.
You can create as many of these diagrams as you like – multiple perspectives, “as is” and “to be”, overview and details, whatever works for you. Decisions and other objects can appear on many diagrams and the DecisionsFirst Modeler database stores all the links you make on all the diagrams.
Let’s get a decision requirements diagram created. Name the diagram “Support Decisions” and click “Add Diagram”.
On the left hand column of the page are the three objects you can create from the diagram. These objects are Input Data (oval), Decisions (rectangle), and Knowledge Sources (document). Additionally, you can also create Groups (dotted rectangle) and Annotations (bracket shape). Connectors create the dependencies between objects that are stored in the database.
The first step in any decision requirements modeling exercise is to brainstorm the set of decisions you think you are going to be working on and put them on a diagram. For BigCo, four decisions have been identified in the support and service area of the business - Determine Refund Eligibility, Determine Return Eligibility, Calculate Price and the new one Select Marketing Offer. Let’s go ahead and create these four decisions.
Select the Decision Object and drag it onto the diagram. On the right hand side of the diagram, enter its name and description. Name the decision “Determine Refund Eligibility” and enter the description “Customers often request a refund to a fee on their bill and a decision must be made each time as to whether to refund all or part of the fee. #support #tutorial” This decision now exists on the diagram and in the database.
TIP: You will notice that we added "#support #tutorial" to the description. This tags the object with these two tags. You will also notice that subsequent objects will also contains tags. You don't have to include tags in descriptions and you can include one or more if you do - simply type the tag text anywhere in the description field. Additionally, tags can be used in object titles. These tags can be used in search, as we will see later, to help you find the objects you are looking for. This is particularly helpful once you have multiple projects in the database. Adding #tutorial to every object you create will mean you can rapidly find the tutorial objects in the future once your database contains your own projects.
Repeat this sequence to create the other three decisions. You will want to move each Decision as you create them so they don't overlap:
|Calculate Price||When an order is defined a price must be calculated that applies volume, promotional and customer discounts as appropriate. #tutorial|
|Determine Return Eligibility||When a customer requests a return it must be assessed to see if a return is allowed or not. #support #tutorial|
|Select Marketing Offer||Every time a positive or neutral interaction happens with a customer BigCo wants to make a marketing offer to cross-sell or up-sell them. #marketing #tutorial|
When you are done you should see four decisions on your diagram.
TIP: When you are doing this for your own decisions, remember to focus on repeatable decisions. You can use DecisionsFirst Modeler to create models for one-off decision making (“should we drop this product line” for instance) but it is primarily designed for modeling the approach you want to take to a repeatable decision such as those listed for the tutorial.
Before we do anything more to this diagram, let’s introduce a few of the diagram features:
- You can move nodes around by clicking on them and dragging the node itself.
- If you have a single node selected you can edit its name or description using the properties on the right hand side.
- You can select several nodes by dragging a box around them and you can then move the group by clicking and dragging any of the members of the group
- Clicking anywhere in the diagram not on a node deselects all the nodes
- You can select any object to open the object for editing
Creating Input Data
Next we will add some Input Data. Making Decisions requires information – information about the case being decided, reference information, information about customers and more. While DecisionsFirst does not model databases, it does allow you to document the sources of information available so you can identify which input data are relevant to which decisions. For BigCo relevant input data include Product Catalog, Issues List, Orders, Customers, Bills and Marketing Offers. Right now we will create one of these Input Data from the diagram.
Drag and drop one Input Data Object onto the diagram. On the right hand side of the diagram enter the name "Shipments" and the description "Shipments made to customers #tutorial".
Repeat this sequence to create the other Input Data:
|Product Catalog||Information about all products and services #tutorial|
|Issues List||Known issues with the products and their resolutions #support #tutorial|
|Orders||Orders placed by customers both shipped and pending #tutorial|
|Customers||Customer data #tutorial|
|Bills||Every bill sent to every customer in the previous 24 months is available #tutorial|
|Marketing Offers||Available #marketing offers #tutorial|
Tip: Be fairly granular with the input data you use. Many of BigCo's input data identified here would be in the same database but they are modeled separately to make it clear which information is used where.
Creating Knowledge Sources
To make a Decision we must know how to make it. We must know what steps to take, how to pick the right option and so on. This knowledge is modeled in DecisionsFirst Modeler in terms of knowledge sources or collections of know-how. These can be linked to Decisions to show which know-how is needed to make which decisions. For BigCo relevant knowledge sources include Return Policy, Product know-how, Customer Loyalty, Customer Propensity to Accept, Service Expertise and State Return Regulations. Right now we will create one of these Knowledge Sources from the diagram.
Drag and drop one Knowledge Source Object onto the diagram. On the right hand side of the diagram enter the name "Return Policy" and the description "The company's policy for returns - who can return what #support #tutorial .
Repeat this sequence to create the other Knowledge Sources:
|Support Policies||Different products have different policies regarding customer support #support #tutorial|
|Product know-how||Internal expertise on the products and how they work #tutorial|
|Customer Loyalty||An assessment of the likely loyalty of a customer #tutorial|
|Customer Propensity to Accept||An assessment of the likelihood that a customer will accept a particular offer #marketing #tutorial|
|Service Expertise||The know-how of the support team on what works with customers and what does not #support #tutorial|
|State Return Regulations||Limitations and restrictions on the company's returns that are driven by state laws #support #tutorial|
TIP: There are several different kinds of know-how represented here. The Return Policy is a policy document that is internal to the company and produced by it. Product know-how and Service Expertise are much “softer” know-how and probably exist only in the heads of experienced employees or perhaps in training manuals. State Return Regulations are just that, regulations, legal guidelines produced by some external body that must be followed. Finally Customer Loyalty and Customer Propensity to accept are analytic insight, the kind of know-how we can extract from our data. All these types are valid types of know-how and should be modeled as Knowledge Sources.
Creating Requirement Links
A Decision requires something when it is required in order to make the Decision at all or to make it accurately. For instance, we cannot decide who is eligible for a return without access to information about shipments made to customers so our Determine Return Eligibility Decision clearly requires the Shipments Input Data. Similarly we cannot make this decision unless we understand the return policies we have in place so our Decision also requires the Return Policy Knowledge Source. These are the kinds of requirements we can build on the diagram.
Information Requirements, represented by a solid line and a pointed end , are used to show that a decision requires information. For instance a decision might require the information in an input data.
Authority requirements, represented by a dashed line with a round end , are used to show where the authority for something comes from. For instance the authority for how to make a decision might be the knowledge recorded in a knowledge source.
Tip: You'll also see an option for a dotted linethat is used to connect Annotations to the object they're referencing.
To create a link you simply click the appropriate button to enter link drawing mode and then drag from the source of the requirement to the target of the requirement to create a link. The link will have two ends – the one with the arrow or circle should point to the object that has the requirement and the blunt end should rest on the object that is required. So, for instance, if a Decision requires an Input Data then the blunt end is at the Input Data end and the arrow at the Decision end.
Let's create requirements from the Shipments input data to the Determine Return Eligibility decision and from the Return Policy knowledge source also to the Determine Return Eligibility decision. Click on button with a solid line and arrow to start creating an Information Requirement then mouse down near the edge on the inside of the Input Data and drag to the Decision before releasing. This creates a requirement from the Decision to the Input Data. Click on the button with a dashed line and circle to start creating an Authority Requirement then mouse down over the Knowledge Source and drag to the Decision before releasing.
Note: Make sure your links are snapped into place so when you drag the objects the links stay connected. The object border will be highlighted in red when snapped. The snap creates a link in the database.
The Support Decisions diagram now looks like this:
(You can also create new objects from the Create menu option from the Hamburger Menu. This creates an object in the database that can be associated with one or multiple diagrams.)