One of the most exciting aspects of working with Decisions is how many different business contexts I’m able to learn throughout each day. A common context I’ve found among thousands of interactions with customers and potential customers is application processing. Specifically application processing in financial services.
This problem domain typically includes many regulatory requirements, verification processes with a lot of business logic and data from external systems, and points in the process where a person needs to make some type of decision. These attributes create a perfect storm for a platform like Decisions, especially as all of this business logic evolves over time and where there are real dollars tied to process optimization.
One of the most common sources of definition for these types of processes comes from external regulatory requirements. This could be around how data is treated at rest or in transit. This could also be something more impactful to the actual business process around who can see what data on a given form, or what types of rules you need in place to enforce compliant decision making for both user level interactions and engine only decisions.
Decisions provides a facility for all of these requirements. Decisions can keep a complete audit record of all engine level and user interaction level activity along the way. This audit data is also accessible by our reporting tools for easy to interpret views for auditors to use as needed, or to export and store on any given period.
Decisions also provides a great deal of configurability around adding more mechanisms for regulatory compliance. This could include data access controls, or what a user is allowed to change in a workflow or a rule.
Another common scenario is preparing for regulatory updates. Decisions provides date oriented settings for rules that can be developed and tested prior to the go live date and deployed ahead of time with a timer that will enforce the new logic at a specified date and time.
Any lending organization has the responsibility to optimize their portfolio against certain business objectives. Decisions about what clients are eligible, variables within certain products, and how to service these clients are constantly being questioned. In some organizations this can add a tremendous amount of overhead as analysts present findings, management approves changes, and then project managers meet with IT to kick off lengthy code level development cycles to identify where business logic is buried within their applications to enforce new business objectives.
This is the classic business case for a business rule engine: 1) centralization and 2) rapid optimization. Instead of developers chasing down stored procedures in several different applications – forcing the re-staging and re-deployment of assets for simple logic changes – we want to have a centralized place that can be updated as a reference for other systems. With this master logic reference organized – we then want to meet business users in a place where they don’t need to learn any type of special script or syntax to change this business logic. We want them to be concerned with the data and logic of their business. We want business users to log in, see the outcome of existing rules, update a threshold value in a given rule, and monitor the impact of that change. No project manager. No developer.
A primary value proposition of Decisions is the ability to take work away from employees and turn it over to the machine. One of my favorite examples of this was with a boutique lender who was processing around 800 applications per month per dedicated person. This job entailed taking raw application data from an online form submission and manually entering that data into an excel spreadsheet to determine eligibility for different products they could offer. This created real business constraints in terms of how many customers they could serve in any given month.
After implementing Decisions, the application processing capacity of that team increased 10X, and in some ways became virtually uncapped through auto approval and rejection mechanisms. This team really started to focus on the exceptions or special cases in these applications – and they continue to explore how Decisions can be used to further automate these exceptions and special cases as they continue to learn.
We’ve worked with teams who have very clear requirements surrounding their business processes, and we’ve worked with teams who came with a broad objective and wanted to learn from our experience. We are happy to deliver solutions in both models and would welcome a conversation if you contact us at firstname.lastname@example.org.
Decisions is the quickest way to build software and solve your most difficult problems. Book a demo to learn how we can simplify and standardize your business operations.