How to Avoid 10 Common Mistakes in WMS Implementations: Part 3

Topic 3:  Lack of Risk Planning

In our initial article we presented 10 common mistakes made during the implementation of any WMS application. This article is the third installment in the series and will focus on the issue of ‘Lack of Risk Planning.’

In our opening article, we stated that incorporating a Risk Plan within the overall implementation plan is vital. Many WMS implementations exclude risk planning and as a result, fail to meet implementation schedules due to the fact that they fail to predict the “what if” aspects.  In fact, projects without Risk Management Plans are significantly more likely to take longer, go over budget, and ultimately they may even fail.

To mitigate this, the Risk Management Plan (RMP) should be developed and approved even before the project begins.  Failure to create an RMP up front is a little bit like forgetting to create a fire department in your town.  Everything is fine until there is a fire.  Then everyone will be running around screaming ‘every man for himself’ because no one knows who to call, or what to do.  Even worse, they don’t have any of the tools or knowledge on hand to prevent the situation from escalating.  Even when the fires do get put out, no one can assess the damage and get everything back on track.

Alas! Risk is part of any project and all Team Members must be made aware of the risks up front and know how to recognize the emergence of the risk and alert the Team to take action. This is where another common mistake generally happens. Everyone knows something is going wrong, but there is still a failure to take action!

The project manager should ‘facilitate’ the development of the RMP with each Team and with the Management Team. The RMP should identify the major “risks” for the project, the potential impacts or consequences and finally, a plan to either eliminate the risk or significantly reduce the potential impact. This is generally defined by a “Risk Matrix.”  In general practice, the following risk management strategies are generally used within an RMP to categorize risk, though there are numerous variations.

  1. Accept the risk = Take a chance on the negative impact and adjust plans accordingly.
  2. Transfer the risk = Outsource the risk to specialists who are experienced in handling the risk and have the resources to minimize the consequences.
  3. Avoid the risk = Adjust plans to eliminate the risk or reduce the consequences to a minimum.
  4. Mitigate the risk = Take immediate action to lessen the impact.

Categorizing risk also helps define your response strategies a little more generally, so that unforeseen issues can still be categorized and summarily dealt with in a manner consistent with your overall risk strategy.

If you’ve bought into the idea of an RMP, then the next step is to figure out how to create one.  Generally, there are 4 basic steps to creating a RMP:

  1. Identify the risks.
  2. Qualify each risk in terms of impact and probability of occurrence.
  3. Incorporate the risks within the project plan with triggers that activate the risk action plan.
  4. Create monitors that alert the project teams to the occurrence of the risk and actions to be immediately taken should the risk emerge.
  5. Continue to monitor the risks.

One of the best practices for a successful WMS implementation is the incorporation of the Risk Mitigation Plans within the actual project plan. The mitigation plan is in actuality a series of sub-steps within the project activity step that defines and assigns tasks that are intended to minimize the risk. The following is a basic representation of this concept.

In the illustration above, the risk actions have been incorporated into the project plan as a series of sub-steps that are triggered if the risk emerges as a realistic possibility. The main project activities continue in parallel with the risk action steps which have been designed to “mitigate’ the risk (minimize the impact).

 

An example might look something like this. Activity X is a planned data load and Activity X+1 is the validation that the data load was successful. In addition, there is an identified ‘Risk’ that during the data load there may be issues. If no issues emerge, then Activity X passes directly to X+1 (Validation). If an issue emerges, ‘Risk Step 1’ is triggered and the data is corrected. The data is loaded in Risk Step ‘N’ and flow continues back to Activity X+1.

 

There are hundreds of Project Risk Management and Project Risk Analysis templates available, and which one you choose is largely a matter of personal and organizational preference. The important thing is to select one that works well for the current project and integrate it early in the planning stage. There are even several add-ins for Microsoft® Project Management that seamlessly integrates a RMP into the project schedule.

 

Bridge Solutions Group understands that your business is unique, which is why we integrate our best practice knowledge with your organizational strategy seamlessly. We have the experience, skills, and resources to assist any organization in the development of a Project Risk Management Plan that is pertinent to their industry, software package, and business.

Manage Misuse Fee

With online selling channels taking off globally, retail and online consumers have begun using credit cards for payments like never before. Authorizations secured on the customer’s cards have an expiration time (for eg. 3 days for debit cards, gift cards, 7 days for credit cards), depending on the rules specified by the banks. Recently VISA has introduced “Visa Authorization System Misuse Fee”, which introduces new fees for processing credit card transactions for transactions not conforming to VISA rules and processing guidelines. A fee will be levied, in addition to the normal transaction fees, against merchants if authorization is not reversed and gets expired or if the auth is only partially used. Many retail companies revenue comes in from these type of transactions and therefore, managing the costs incurred because of these becomes increasingly important. Let us look at the two points below describing the problem in detail and then the solution for it.

1. If an authorization expires without a settlement transaction initiated against it, a misuse fee is charged by the payment processor to the retailer. Suppose, an auth is taken while order is getting created and is set to expire within 7 days. If the fulfillment and settlement of the order does not happen within 7 days due to inventory unavailability or customer not turning up for pick up or failure of shipment confirmation etc, then auth will get expired and misuse fees will get charged to retailer.

2. Failure to match the settlement amount with the authorization amount also results in the misuse fee being levied by the payment processor. Any type of cancellations or modifications on order which result in amount on order to increase or decrease may result in situations when the settlement amount does not match the authorized amount.

credit cards

To explain the current behavior, let us consider a scenario. While creating an order, an authorization equivalent to the total order amount is created. When invoices are created and settled, this authorization is used against the invoiced amount. So when order O1 is created an authorization, say A1, equal to the order total of $70.00 is created. When the order is scheduled and released and say two releases R1 (for L1), R2 (for L2) and R3 (for L3) are created and so correspondingly three shipments and three invoices I1 (10$), I2 (20$) and I3 (for 40$) are created. So, when invoice I1 is settled it uses only $10 out of the 70$ available against auth A1. So there is a misuse of auth A1.

To avoid levying such a fee, the IBM Sterling Order Management solution has introduced a new feature called “Charge Transaction Request and Auth reversal”. Authorization reversal is the process of removing the authorization hold on the customer’s card by invoking a reversal transaction to the payment processor. The reversals ensure that the authorizations don’t get marked as misused. “Misused Authorizations” are defined as authorizations that are not followed by matching clearing/settlement transactions and are subject to a fee.

The charge transaction request feature allows users to have a fine grain control over when and how much authorization is created for an order.  A charge transaction request (CTR) represents a subset of the total order amount that will be invoiced.  Typically, CTRs are created on creation of releases, as they provide a fairly accurate picture of the eventual shipments and invoices. In the example above, once the potential releases are identified for the order (R1-10$, R2-20$, R3-40$), when the  Order Release(s) get generated, logic can be applied to delete the old charge transaction requests (CTR) and create new CTR’s equal to the number of releases and the corresponding release amount. When a collection request occurs, the authorization A1 is reversed since the authorization amount does not match the CTR’s present and new authorizations A2-10$, A3-20$ and A4-40$ are created. This reversal of authorization and creation of authorizations is handled effectively through simple product configurations, and helps in reducing the misuse fee levied due to Authorization misuse.

This is a common case of authorization and settlement not matching and may happen quite often during order fulfillment or modification process. Because of the misuse fees introduced by VISA, many major retailers are beginning to turn to auth reversals so as to avoid any extra charges by banks on them. As this type of fee gains more popularity amongst credit card companies, we at Bridge Solutions expect that reversals will become a standard practice amongst anyone who takes even a modest number of credit card orders.  If you would like to learn more about reversals, the IBM Sterling Order Management Suite, or payment execution best practices in general, please contact us at contact@bridgesgi.com.