Last Thursday I questioned whether IT spoke the language of business. In that short commentary, I used a couple of examples. One of them was “abstraction.” I mentioned that, “if you tell a business person you can set up rules that will govern processes once, and those rules will be enforced by all your business systems, then you have introduced the concept of abstraction without having ever said the word.”
Today I read that Activant has introduced a Business Rule Engine for Distributors. This is exactly the type of feature I was talking about – one that takes the solution beyond the traditional transaction and reporting ERP of old. The Business Rule Engine provides Prophet 21 users with the ability to insert their own business logic into the Prophet 21 code base without altering the application code itself.
Some examples provided by Kevin Roach, executive vice president and general manager of Activant's Wholesale Distribution Division included:
· Conversion rules that auto-populate some fields based on others - like the town or city and state based on zip code? These are the types of “smart” features we have become accustomed to through our own personal online shopping experiences. Heck, I was a catalogue shopper long before the Internet and even back in those days I had customer service reps automatically filling in my town and state based on my zip code. But I didn’t see the same intelligence in business applications. This is a very simple example, but there are scores of ways to use this kind of functionality. Like certain compliance requirements based on type of product. Activant suggests an item entered with a product group of Pharmaceuticals could automatically set the Pedigree Tracking Checkbox to be checked. Or food and beverage for nutritional labeling, etc. As new requirements are added, new rules reflect the changes with far less disruption than mucking around in code.
· Validation Rules: Another Activant example, Customer A can only buy items with Item Class 1 set to "No Restrictions." The system will provide an error message if an item without that Item Class is entered on an order for Customer A. These validations basically allow for the creation of warnings and error messages based on rules being met or not met.
· Asynchronous Workflows. A third Activant example… a distributor could set up a workflow so that a purchase order placed in the amount of $5,000-$10,000 triggers an alert to an authorizing manager for signoff, while an order over $10,000 triggers an alert for the CFO's signoff. When the inserted trigger is activated in the Prophet 21 software, the rules included in that workflow will be executed in the sequence indicated. Those are the rules today, but perhaps during a downturn in business, you need to (temporarily?) reduce those authorization levels or require the CFO to additionally review all purchases. Perhaps the rules tomorrow will add the type of purchase. Maybe a requisition generated for direct materials will be handled differently than indirect materials.
Why are these features and these examples (which appear to be so simple) so important? Because these business rules are subject to change. And if they are embedded within the logic of the application then changes to your business either require changes to your application (think source code and programming) or prevent your business from adapting.
If you are using older, outdated technology, and looking to upgrade or replace…perhaps this type of requirement is not top of mind. But all ERP users should be clamoring for this type of logic to be extracted (or abstracted) from the underlying code so that it puts the power of change in the hands of the business user.
No comments:
Post a Comment