Three questions every organization should ask (and answer) before implementing Sterling Commerce’s SMCFS pricing module (V8.5+)
The Sterling pricing service is an interesting new animal within the Sterling Commerce suite of applications. A strategic decision was made to absorb much of the Comergent acquisition’s pricing functionality into the product, and to retrofit Sterling’s core framework and API’s to utilize it. Although the deprecated pricing functionality will still be available (for at least the short-term of future releases).
this article is meant to stand as a signpost to those looking to utilize the new, and dare I say it, improved functionality provided. But there are three key questions you need to ask yourself, in order to get the most out of your implementation. Those questions are, of course, who? when? and what?:
- When? -– What are the performance metrics?
- Who?—Who are the users I expect to use the pricing capabilities?
- What?– What do I want the pricing engine to do?
Bear with me. These generic questions, if framed appropriately, can mean the difference between an on-budget, on-time, and above expectations implementation, and a frustrating, costly, and unhappy experience. So, what does this mean?
The When:
In this scenario, the when, is more appropriately labeled the ‘how fast’. In a service-oriented world, the speed of an application is not only important, but key; How many applications can call the underlying services, how many pricelists and pricing rules can be loaded while maintaining a sub-second response time, and how often/quickly can the pricing master data be loaded? Fortunately, the answers to all of these questions, within their appropriate context, is almost always the same– FAST.
What does this mean? IBM’s own published assessments of this functionality estimate that few ‘out-of-the-box’ configurations, with reasonable amounts of master data (for your context, my most recent project involved thousands of pricelists and pricing rules, applied to 90,000 customers), establish sub-second response times for high volumes of calls. Complex if/then pricing rules, dozens of active price sets, and large message volumes (5-100 lines) can all be assessed quickly and accurately within the pricing routine. But the user exits themselves can become prohibitive.
Slow response times for the UE’s, combined with the risks of custom coding, can make extending the application challenging. The key takeaway for the pricing components is that the out-of-the-box functionality is FAST. Custom can, and will, only slow it down, usually disproportionately so. For those interested in getting the most out of their application, read on past ‘the who’, to ‘the what’.
The Who:
Sterling’s business center exposes tons of functionality to users, much of which can affect the application’s pricing behaviors in drastic ways. Seemingly small configurations can impact things like product entitlement rules (the capability of a buyer or seller to have access to an item), pricing rules and coupons (changes to the prices of an item or order), and shipping charge discounts/charges. Changing these can and will impact your bottom line, and should be controlled tightly. High complexity, combined with high usability, can be a potent combination, and training of resources will be key to a successful implementation. Key concepts that resources accessing this UI need to understand are:
- Seller and Buyer entitlements
- Attribute and category assignment
- Pricing rules and inheritance
- Pricelists and derived pricelists
- Shipping charges, surcharges, and discounts
- Catalog management
- Test Pricing
The UI’s for Business Center is highly user-friendly, which carries both a benefit and a cost. There is currently little user-security capability for the business center, which means that users will feel enabled for all capabilities. Having been involved with users during their learning period, their pain points have been centered around: navigation, understanding of the impact of configurations, and visibility into master data’s effect on the business center. The keys to understanding and presenting these concepts are demonstration and scenario-based exercises. The more successful implementations of this typically involve recorded demonstrations, searchable documentation, and impact-based behavioral contexts (i.e. if you click this button, this blows up).
The What:
Requirements, as with any project, are especially key when deciding how, and if, you will utilize the Sterling Pricing component. The product itself handles most business requirements through configuration, and through user-exits (aka customization) many solutions can handle the rest. However, the user-exits provided are very limited both in scope and in sequence of execution. Sterling does provide custom user exits that essentially bypass all of the Sterling application’s logic (pricelist assignment, pricing rules, coupons, shipping discounts, and all the fun stuff), but if, like many, you bought a packaged application in order to utilize its functionality to its fullest, then you need a clear understanding of the events, and just as importantly of the sequence of events, within the pricing engine.
Limited implementations of the pricing component have been done since it was integrated into Sterling (I was personally involved in what I believe to be the first implementation of the pricing engine at a client), so finding the right people to implement your solution can prove to be difficult. So, you are probably asking, what can I do to facilitate a better implementation for my own company? A detailed roadmap of the sequence of events of the pricing engine can be the most helpful tool to help your team understand and best implement the product. There are hundreds of steps that occur in the pricing engine (at a higher level, I last counted 274), each of which impacts those downstream. Knowing how these steps interact will save you time, money, and tons of frustration in your implementation.
In Conclusion:
The Sterling commerce pricing routine is a very flexible, capable, and performance-friendly component of their commerce suite. Given the right combination of business competency, expertise, and product knowledge, a team can implement this routine to meet and exceed most expectations quickly, easily, and with minimal pain. Bridge Solutions Group has a team of highly trained consultants and architects that can provide you with the deepest knowledge and significant value as subject matter experts, implementation experts, training partners, or anything in-between. We have thoroughly researched, worked with, and pushed the limits of the pricing routine in the context of several different key user profiles; whether you are following a complex wholesaler pricing model, online e-tailer pricing model, traditional retail model, or a diverse multi-channel, multi-enterprise pricing model, Bridge Solutions can help bridge any gaps in knowledge, resources, or capabilities that you may have.
Author: James Brochu, Applications Architect – Bridge Solutions Group
You can email us at: [email protected] or call us at 1.877.245.4347