Supply Chain Management

Many organizations face multiple challenges during ERP implementation due to various reasons; few of them are absence of key data, presence of duplicate data, load errors, incorrect data, etc. This actually leads to incorrect transactions, inconsistent reports, regulatory compliance issues and lack of customer satisfaction.

So, data plays a very significant role for Go-Live & organizations use data templates & tools to load bulk data into the system. Praveen has rightly said that "EAMs are data eaters & master data management is a a critical aspect in EAM implementations" in his blog "Why my EAM implementation is not giving me as I expected?"

There are various checks & balances which you need to do to get this right first time. The below mentioned are the best practices for a master data load based on my own implementation experiences. I have categorized the best practices into various categories as mentioned below

Preparation for Master Data Load

• Prepare a list of data you need for Go Live
• Create a sequential order to load those data
• Identify the data which you need to create manually and the data which you need to load using load tools or other uploading methods.
• Categorize the master data into Organization specific data, user data, finance data, Meta data etc
• For each category, identify an owner to extract the data from various sources.

Validating source data before transferring into data templates

• Validate the source data, correct errors, correct duplicates, etc before you transfer the data into new data capture templates.

Preparation of Data capture template

• Prepare a data capture template to match the ERP application
• Prepare a data capture template per application or per master data like Item Template, Vendors Template etc
• Define basic validation rules (below mentioned) in the template to minimize the errors in data before loading
• Mandatory fields should not be left blank
• Key information should not be left blank
• Duplicate data should not exist
• Spelling should be corrected in detailed descriptions or terms & conditions
• Junk values should be avoided by having drop down lists in the fields
• Setup a checklist and instructions for filling the data so that the person who fills the data can do a self check & correct errors if any. Also mention some of the important business rules as part of this checklist so that the person can validate those checks also & correct errors if any.

Please add if you have come across any best practice related to master data load in your earlier implementations. In my next blog, I would like to continue the same category "Preparation of Data capture template" in a bit more detailed manner and also discuss about "Pre Load data validation".

 

 

Posted by Jamuna Chinnathambi at 3:00 PM | Permalink | Comments (0) | TrackBacks (0)

This blog of mine is quite different from all my blogs. Instead of trying to analyze what trends I see or what directions I construe in supply chain management, here I will share with you some of my experience during a recent presentation at the Supply Chain World Conference in Singapore. We (Infosys and Honda) were invited for presenting at this conference on some of the innovations carried out in supply chain inventory optimization and distribution lead-time management

The gathering was a mix of industry practitioners in supply chain from the high-growth markets of India, China, SE Asia and South Africa; as well as the developed markets of North America, Europe and Japan. I have termed these as "high-growth" markets.... since I could realize in the Conference that these "emerging" economies have actually emerged and evolved their unique strategies. We were invited to present on the vehicle supply chain à order and distribution management improvements carried out in India market, experiencing double-digit growth. The topic specifically delineated on the challenges faced in these markets and the supply chain strategies required for implementing late-customization, inventory optimization and reducing replenishment lead times. What was most interesting, were the types of questions asked by the audience, which reflected the nature of problems faced in their organizations.

There were questions on strategies which could be adopted for developing supply chain systems which would enable inventories to be slashed across the pipeline and in the stockyards of the channels, without allowing their channels to indulge in trading among themselves. These issues clearly demonstrated the prime focus on inventory reduction among the manufacturers in these high-growth markets. But what was also evident was the constraint among these manufacturers who would not take the benefit of trade among their dealers/ distributors to free up tons of inventory locked in individual dealer's stockyards. Unlike the developed markets where such practices are welcome by manufacturers, in these "high-growth" markets the perception that "allowing such operations is likely to reduce the manufacturer's control over these dealers" prevents accepting such dealer trade practices.

Another notable observation was the focus on reducing replenishment lead times across the supply chain through visibility. Though it is a no-brainer that visibility would reduce planning lead-times and slash supply and delivery lead-times, but was came out as an "outlier" observation was the questions on KPIs and risk-management methodologies which would enable developing early warnings for delays, escalations and exigency costs. What executives in supply chain were scouting for, were quick-deployable low-cost solutions which would enable them watch systems from remote and take decisions as early as possible in the problem-life-cycle.

 It is evident, that the manufacturers and supply chain managers of these markets are not taken-away by the stupendous growth, but are more cautious that they don't fall into the trap which their counterparts in the developed markets ignored. They are still focused on inventories and replenishment lead times, to maintain the lean structure that they would like to retain. The only item they have to learn is sense the growing maturity among their channel partners and enable them support these goals, by giving greater autonomy; though it may be perceived as loosening their "traditional" grip on these partners

Posted by Sudripto De at 6:34 AM | Permalink | Comments (0) | TrackBacks (0)

A couple of weeks ago, we were helping our clients figure out the landscape across the various packages they are implementing in their Ecommerce space. One of the main issues that was covered during this exercise was the seeming overlap of functionalities between the Order Capture Ecomm suite and the Order Management suite.

I have been asked this by multiple people with slight nuances at various client sites over the last two years.

In a pure Multi-channel solution, the Order Management layer is primarily tasked with consolidating demand (Customer Orders) utilising a consolidated inventory picture (Available To Promise) and fulfillment capability (Sourcing). But this vision tends to stay idealistic in most implementations that I have seen with some 'short-cuts' and 'work arounds' being put in place for a variety of reasons.

The squeeze on the Order Management System comes from both sides, i.e. the Order Capture systems and the Order Fulfillment systems.

One of the main trends that I see with big retailers is a move towards a consolidated Order Capture. I have been working with at least 2-3 clients who are trying to have a common Order Capture UI for all channels as part of their overall Multi-channel strategy to keep features and functionalities similar. This trend is helped by products like ATG Webcommerce which supports (with some extensions) Order Capture through the three main channels of Web, Contact Center and Stores.

Another trend which feeds from the above is the push by the Marketing/Online Business team to provide more and more dependable inventory information online. While this is a 'bread & butter' area for Order Management, performance considerations drive the push of the inventory information into Order Capture layer to reduce 'network chatter' and speed up the rendering of the web page. In most cases, this cached inventory gets used by the Order Capture system for taking the Order thereby reducing the dependency on the Order Management System.
Both these trends tend to move some of the inventory consolidation into the Order Capture product.

On the fulfillment side, a lot of retailers already have some sort of mini Sourcing systems in place either for a set of products or a set of warehouses. These systems tend to be stable and usable with Scalability being the main issue. This drives a lot of implementations to reduce the implementation complexity and time by integrating with these systems rather than rebuilding the atomic links to each individual warehouses.

Another trend is for scalability to be built through Direct Dropship rather than increasing Warehouses. This generally ends up being done through a Supplier Network or a Supplier Portal.
And finally, with networked-WMS systems being available (like the Sterling n-WMS), fulfillment consolidation and even inventory consolidation across various Warehouses can be functionalities leveraged within the Fulfillment systems.

With such a lot of constraints driving towards a hybrid approach, my gut tells me that we will start moving towards a a more consolidated approach to MCC from a product point of view with Order Capture and Order Fulfillment products picking up the OMS functionalities between them.
 
I would like to hear from others on this both in terms of opinions and in terms of experiences.

Posted by Prasad Acharya at 10:57 AM | Permalink | Comments (2) | TrackBacks (0)

Retailers are always looking to maintain optimum inventory levels to meet fluctuating market  demands and not to over stock goods thus increasing inventory carrying cost. The Available to Book - ATB model allows the retailer to allocate stock for future demand without having physical inventory available at the DC. Demand which needs to be fulfilled at a later point of time in the future is allocated against a future supply which will be made available as onhand stock close to the future date when the demand needs to be fulfilled.

In this blog, we will look at what changes need to be adopted before applying the ATB model -

Supplier Categorization - ATB Model relies heavily on the efficiency of the supplier to supply the right goods at the right place and at the promised time. Those suppliers who have an excellent track record of consistency in their deliveries and who are capable of sustaining the same in the long run are the ones who need to be included in this category. This means that a demand that is allocated to a supply promised by such a supplier to arrive at x date in the future will reach on time each time. Only such goods supplied by these suppliers would be considered for this model.
But it is not always that the supplier is capable of supplying all items precisely on the promised date. There could be certain items when the supplier will not be able to supply on time, so in such a case supplier-item categorization needs to be done to filter out those items which the supplier has lesser capability of delivering on time. 
   
Order Taking Channels - These channels (website, Stores, Contact Centers etc) need to have real time updates not only of the physical inventory levels, but also on when future supply is available for the same item. Not only will this will help in allocating future stock to future demand, it will also free up onhand stock to be made available for demand that has to be fulfilled immediately. Absence of such updates would mean onhand stock being allocated even for demand that needs to be met in the future. 

Customer Service and Order Management - Any change in the customer's requested date would require re-allocation of stock already tied up to an existing future supply. If the new requested date by the customer is much closer to another supply coming in than the earlier one, the closest supply needs to be allocated to this demand.  This means that there has to be a high level of coordination between the supply team and customer service teams, and real time supply availability picture has to be made available to contact center and customer service teams.

Posted by Lokmanya Rawat at 8:10 AM | Permalink | Comments (1) | TrackBacks (0)

Recently, I read an article on Tesco's grocery ecommerce site that halted on December 5 after the surge of customers who tried to take advantage of the loyalty-card promotion. The article brings out an important point that getting the cloud working for sudden surge in volume is not as easy as it sounds even though one of the main advantages of the cloud offering is the ability to scale up processing power on need basis.

Let's consider how cloud offering should work in multi channel commerce solution. Processes starting from product search in website, availability check, make payment, fraud check, allocate order, send order for fulfillment/shipping, invoice to settlement can theoretically be on cloud. At a high level it appears that majority of these activities can happen in cloud without any requirement of ecommerce processes to connect to the "corporate systems". However, if you analyze and go into details it may not be true. For example, processes such as payment integration, loyalty point reimbursement, settlement or inventory availability check may require cloud to connect to corporate systems. If you take example of TESCO, the article mentions that, only certain ecommerce functions were entirely on the cloud. It is like an à la carte menu of cloud-service offerings by a cloud service provider from which a company will choose. Accessing loyalty data may still need to go through TESCO systems which may become a bottleneck.

There is lot of buzz and inquiries for multi channel commerce on cloud. I came across at least half a dozen enquiries in the last 6 months or so. But a majority of these clients seem to be trying to do something very quick, cheap, get it up and running in a very short time. However, my perception is that, some of these are short term solutions and the strategies could be very risky if the entire solution is not well thought through. Multi channel commerce is not just running a website on the cloud. Most of the cloud providers in this space have some "quick fix" for running a website but it is not a long term multi channel offering i.e. features such as cross channel integration for better customer experience, intelligent inventory allocation across various fulfillment options, distributed order management may not be available in cloud offerings. Some of these features on the cloud will still require a way to connect to the corporate systems without which the solution may be working on "static data"!

Large multi channel commerce players such as Target have decided to bring these operations in-house. At present, for large retailers, it looks like major part of their multi channel commerce will continue to be in-house and may be some part of (B2B or low volume ecommerce) business could be looked at moving to cloud to reduce capital expenditure and faster time to market. However, if someone is able to provide complete end to end processes (theoretically sounds possible!), it sure can be the way to go in the future.

Posted by Vinayak Hegde at 7:52 AM | Permalink | Comments (1) | TrackBacks (0)

I first heard the term "Agile Supply Chains" during my initial years in supply chain; and naturally summed-up my understanding purely going by the literal meaning of the word "Agile" (which was fairly reasonable). I then came across a paper titled "The Triple-A Supply Chain" that beautifully explained how supply chains can become agile. And during my study sabbatical, I had the opportunity to study this subject in greater detail.

 

So, we understand that the age-old mantra of running supply chains efficiently and measuring it on only two parameters - cost and service - is no longer sufficient (the "Efficient Supply Chains"). That to gain a competitive edge in manufacturing/service operations, supply chains needs to not only be able to rapidly respond to the customer's demand ("Responsive Supply Chains") but also demonstrate flexibility and nimbleness in minimizing supply disruptions.

 

And how does one achieve this? By forging supplier partnerships (via integrated processes and information sharing); by turning demand driven instead of forecast driven; by actively hunting for postponement opportunities in the supply chain; by building a streamlined logistics/distribution network and lastly by building inventory of critical components (much to the chagrin of die-hard JIT proponents). However, I believe that for all these measures to be effective in an organization, the organization needs to have a culture of fast decision making.

 

Let me illustrate this in the domain I know the most i.e. Software Services. Quite often, the challenge in the biggie IT firms after bagging a large deal is to quickly staff the program. The challenge multiplies if the program spans across geographies and across various service lines; there-by cutting across the firms' business/geographic units (essentially involving various decision-makers). Now in such a scenario, you may have established all the necessary Agile measures such as actively sharing advance information with sub-contractor/recruitment firms (aka forging supplier partnerships), maintaining a resource-bench of key skills (aka critical inventory) and having the visa and travel processes set-up for quick deployment of resources (aka streamlined logistics). But if your organization's culture and set-up does not promote an environment of quick decision-making, all these measures will fail to yield the desired results. For instance, delays in budget approvals for sub-contractor hiring or for visa/travel bookings; or delays in "releasing" resources from under one "umbrella" to another vastly hampers the firm's agility.    

 

Agile organizations are not just those that have agile processes; these processes need to be fueled by an "Agile thinking". How do you achieve that? Well, that calls for another post; but if elephants could dance over a decade back, so can you!!      

Posted by Amit Tambi at 7:24 PM | Permalink | Comments (0) | TrackBacks (0)

Most of the Demand Planning applications like SAP APO, i2, Manugistics, Demantra etc offer statistical forecasting as one of their major differentiating functionality. Statistical forecasting generates the forecast for future periods based on history data provided. Lots of algorithms are on offer in these suites. Sometimes as many as 30 to 40 different algorithms / methods / Forecasting Strategies (All are different terms used for same thing) are on offer. Statistical forecasting is a bit complex and "not so easy" to understand feature. More the number of algorithms more the confusion it creates in the mind of end users. To tackle this problem almost every demand planning suite has a "Best Fit Algorithm". This algorithm is supposed to be "Superset" of all algorithms. If planner applies this algorithm then in the background all possible combinations of all algorithms will be run and one that will give "Best Fit" in the history data will be chosen and forecast generated based on that algorithm. Many call this algorithm as "algorithm for dummies". Generally it is observed that those who do not understand the statistical part of algorithm use this option more to save the trouble. However in 9 out of 10 cases this algorithm generates forecast which is wrong and cannot be used for planning purposes. Why does this happen?

Posted by Nikhil B at 10:05 AM | Permalink | Comments (3) | TrackBacks (0)

While Availability Management stands mostly on its own as a functionality right somewhere in the slush zone between Planning and Execution domain, there are some watch-outs that are very crucial to make your Logistical Model work seamlessly. Two areas that standout while modeling Availability Management, that have a bearing on Logistics Management, are Scheduling and Rounding.

Scheduling Function is crucial to arrive at points in time when a specific Order has to be Transportation-Planned, Availability Checked, Picked, Loaded and Unloaded at a customer destination. These scheduling rules-based calculated dates and times are important inputs to Transportation Management (TM) solution. These inputs help the TM solution arrive at an accurate picture of when a carrier should pick up the load, and when the Logistical Organization should negotiate with the customer for timely arrival of their shipment. This process, by definition, is very iterative in nature and thus a TM module typically comes back with a proposal on Load-ready date and time (a.k.a LRDT) most efficient and suited based on cost considerations. This input plays an important role in ensuring that the loop between Availability management and Logistical management module is closed and complete. This is a best industry practice. If such a handshake is not done between the two functions, it leads to possible distortions in the Supply Chain in terms of irrelevant information.

Rounding function helps manage the Sales Order in unit loads best suited for Logistical purposes such as handling of material through various steps of Shipment planning, and even price optimization. In many instances Orders are priced based on the granularity of the order quantity unit of measure. If customers order in aggregate unit of measures, the logistical savings can be shared with the customer. Thus the per-unit cost savings can be passed on to the customers. There may be smaller customers ordering in granular units and bigger ones in aggregate units. By taking Shippable unit load considerations, it is possible to manage constrained supply in a manner that improves overall fulfillment metric of your supply chain and give forward visibility to client-facing organizations on availability of unit loads corresponding to Shippable units.

The cross-functional nature of the above two considerations helps manage the Supply Chain better by making the Availability and Logistical Management functions communicate on a common-ground and closing important gaps, that are otherwise deterrents to efficiency of your Supply Chain. So, the next time someone proposes a solution in Availability management space, make sure to consider Scheduling and Rounding as two important dimensions to your solution !

Posted by K. Srinivas at 10:03 AM | Permalink | Comments (0) | TrackBacks (0)

In my recent engagement at a consumer electronics client, I worked with the ops planning teams to understand their finished good allocation planning process, build a tool to support the processes and enable opportunities to improve upon

The function of product allocation planning is that of a bridge between the planning and order fulfillment side processes. In the context of multiple sales channels, this function primarily ensures the right amount of supply is being allocated to the right channel partners at the right time

A case for allocation planning

Typically operations planning teams require a robust, real-time link to the order management ATP function. An allocation-planning tool provides this, with the division of finished good supply quantities as input, to manage commits on customer orders in the order to book cycle. In addition, they also want the ATP and allocation functions to work in tandem so that consumption rates from the various sales channels could be monitored leading to re-adjustment of the allocation strategy

To illustrate the point let me give a simple example of a company selling products via reseller channel:

Lets assume that the supply is available in the supply hub at the start of the week, and a small customer places a relatively big order on the same day. Without an allocation plan, the ATP function might commit a large amount of supply to this customer, and sales orders from other customers will be impacted. In a scenario where supply is constrained in relation to the overall demand to begin with, this could lead to impact on fulfillment for regular or premium customers.

The allocation planning function comes into play here, ensuring the amount of product allocation available to the customers is derived based on their demand forecast, current on-hand inventory and product/customer strategy. Thus if the ATP check includes material availability along with product allocation for the customer in the week in question, it only promises the customer's order to the limit of the product allocation planned for that customer.

By monitoring the performance of sales channels (store/reseller/online etc.) along with the incoming supply projections, within a given time period, the supply allocation strategy can be shifted to best suit the organization's mid term strategy.

The benefits can be further enhanced by consumption monitoring and real time re-adjustment of strategy. The ops planners can keep a check on customer consumption levels (in terms of bookings) and react to deviations against forecasts.

In this example, if a relatively large customer had not placed orders against its demand forecast in the week, the product allocations could be adjusted to accommodate larger share for other customers that are doing better than their demand forecasts.


What constitutes an allocation plan

Various factors decide the planning cycle and horizon of the allocation plan. There can be different needs e.g. in a retail context, store replenishment operations would plan the allocation on a daily basis but the horizon could be limited to 1 or 2 weeks.

In my engagement, one important focus for the implementation was on product strategy guidance (NPI or EOL) between the central and regional planning teams. This required an allocation plan horizon stretching across multiple quarters, to drive direction for quarter end inventory targets. The plan would be reviewed periodically based on updated supply forecasts i.e. shipments, in transits from the manufacturing centers and receipts at the regional hub.

Another key characteristic of the allocation plan is that it can be used to drive supply allocations across a mix of dimensions, for e.g. across sales channels (product-channel), across geographies (product-channel-region), or within a sales channel (product-customer-location, product-store)

While there are many more factors that go into building an allocation plan, the above are basic building blocks to start with

 
I will continue to post more on the allocation planning process and share my experiences. Please let me know your thoughts...

Posted by Puneet Arora at 10:49 AM | Permalink | Comments (0) | TrackBacks (0)

Posted by Chandradeep Bandyopadhyay at 11:21 PM | Permalink | Comments (0) | TrackBacks (0)

Recently some of my Infosys colleagues attended MUWG (Maximo Utility Work Group) conference and while they shared their experience about the conference, they mentioned about one of the most discussed topics which was "how to define boundaries for supply chain operations between EAMs & ERPs".

Hence, I thought of sharing my learning from some of my previous Maximo implementations, where I implemented Maximo in following two scenarios:

(i) Maximo for supply chain operations alone, without asset management, and
(ii) Maximo for asset & work management integrated with ERP for supply chain

The supply chain operations considered here are only for MRO spares supply chain or indirect procurement, as relevant in asset management space.

In my view, following should be the main decision making criteria for this situation:

• One User: One system - A business user should not be using two different applications for the same business function. For example, a buyer creating a Purchase Order in EAM for some items and same buyer using ERP for other items should not be proposed. If the buyers are different for different items, then probably they can use different applications but then the organization needs to manage two different procurement applications and would not be able to leverage maximum benefits

• Business, not IT, driven decision - Business is generally the decision maker and should evaluate from business benefits point of view and not from IT cost point of view. Though IT cost is also important but that probably is a onetime initial cost and then some associated maintenance cost, later on. The benefits coming out of business driven decisions may not have short term benefits but would have significant long term benefits from overall usability point of view.

• Interlinked processes in same system - To avoid too much of data floating between EAM & ERP systems, keep similar processes in same systems. For example, from PO approval process to invoice generation process in one system. Some of the intermediate information can be duplicated in other systems like material receipts could be sent to EAM or ERP.

• Integration Complexities - Integration technologies have changed now enabling new levels of integrations. Complexities, risks & pains associated with integrating huge applications have reduced now. Most of the EAMs & ERPs provide APIs which help in integrating to other systems. SOA being the most modern approach, companies should leverage this advancement in technology to maximum possible level.

• Long term Solution - Think from best solution point of view and not from some initial cost point of view. For a robust long-lasting solution, initial cost may be high as there may be more integration points to be developed.

Generally most of the EAM systems have adapters with Tier-1 ERP systems which are flexible and can exchange almost all the information between EAM & ERP systems. Hence the decision should be made considering the best business sense. Leave integration & implementation complexity to your system integrator and focus on best business solution.

Posted by Praveen Kumar Agrawal at 12:07 PM | Permalink | Comments (4) | TrackBacks (0)

The other day, a colleague of mine sent me the brochure of Oracle's fresh pitch to the multi-channel world titled "Oracle Fusion Distributed Order Orchestration - The New Standard for Order Capture and Fulfillment". While the DOO terminology is a slight tweak on the more popular Distributed Order Management (DOM), I read through and noticed a fundamental difference in the pitching of the offering. The text goes thus:

QUOTE
Today, almost all companies manage multiple order capture and order fulfillment systems. In fact, studies show that the average company has 5.2 order capture systems and 4.3 order fulfillment systems. These overlapping and redundant systems create inefficiencies in terms of cost and service. Gathered through channel growth and acquisition, reducing the number of these types of systems is an extremely difficult endeavor with a high degree of risk. For that reason alone, not many organizations are willing to undertake projects that rationalize or retire these systems. Oracle's solution to this dilemma is Oracle Fusion Distributed Order Orchestration, a key component of Oracle Fusion Supply Chain Management. Unlike any order capture and order fulfillment platform in existence today, Oracle Fusion Distributed Order Orchestration seeks to normalize processes and data across multiple capture and fulfillment systems, yielding a single view of order and fulfillment information and decisions.
UNQUOTE

Right off the bat I was wondering whether Oracle is saying "thou shalt reduce your order capture and order fulfillment system"? Noble objective for sure and quite simplistic, but it does come with a bunch of qualifiers. A step back into understanding why these systems came in the first place could illustrate why the DOO argument is not so much of a can-DOO in all situations. Order capture channels proliferated because customers wanted those choices - to walk into a store to touch/feel stuff, to click a promo email & buy through the net, to search & compare from a mobile phone, to rant & rave by calling up a call center (regardless of the 1-800-WAIT-ING lines). Most of the order capture channels were a reaction to customer behavior, so its no use saying we're going to reduce it.

The second part of the story is in the fulfillment side of the house. If the objective is to pick up inventory wherever its lying around (store warehouses, distribution centers, factory warehouses, 3PL storage etc), ship it to the customer and support suppliers via multiple fulfillment models (supplier to end customer or to any hops in between), why would a retailer want to lose that flexibility? The challenge to supporting these order fulfillment models is that in most cases, they exist in their own splendid isolation without even providing visibility into what they are holding let alone more complex asks like supporting split fulfillment.

In summary, the objective regarding "distributedness" should be around "managing" (rather than reducing) these channels. That would mean regardless of from where orders are coming in or items are going out (or how orders are getting split across fulfillment channels), back-end operations remain transparent to the customer. Consequently, there should be no heartburn in all the three primary super-cateogories of order management metrics - customer experience, inventory utilization and cycle time.

Where does channel reduction make sense? If there are half a dozen systems all for capturing orders from stores (for instance, based on geographies, product categories or brands), then there may be a possibility of making life a wee bit simpler for the hapless folks tasked with capturing all those orders (assuming the burden is outside customer's responsibility!). Also, due to M&A, if the acquired company's processes & systems are at divergence to those of the parent company, there would be possibilities in cutting down redundancy. Ditto with under used facilities and too many cross-links from suppliers to various holding points. Where there is duplication, there does exist a case for reduction of channels, but where an organization is catering to multiple forms of order capture and fulfillment, that would be part of the competitive advantage. And one really wouldn't want to reduce that I suppose.

Posted by Gopi Krishnan at 5:43 PM | Permalink | Comments (2) | TrackBacks (0)

Recently, our deliberations with a leading retailer brought to focus a number of process harmonization challenges that it faces across product categories, GEOs and IT systems. These were on account of diverse country-specific processes, multiple WMS systems, lack of unified supply chain metrics, overlapping/conflicting integration requirements, and varied fulfillment strategies. Another discussion with a different retailer that had gone a step further to implement warehouse efficiency & workforce productivity standards at stores also revealed similar issues.

While evaluating potential solutions to address these challenges, I began to wonder at how much the Distribution Center (DC) of today has evolved from its traditional underpinnings without us fully realizing it. For instance, how many of us continue to consider the DC as a cost center while loading revenue center expectations on it? Do revenue-enabling features of warehouse management systems get a seat on the table during WMS package evaluation exercises? Are enterprises viewing their distribution networks in a holistic 'beyond-the-four-walls' framework while evaluating costs? And critically, what must be done to minimize the process harmonization challenges that we observe everywhere?

This note is not an attempt to validate the cost vs. revenue functions of a warehouse. Several posts in the Infosys supply chain management blog have established that by now. The purpose is to secure a baseline on how much the distribution center of today has evolved, and briefly outline what more can be done. In future posts, I will take up these points in greater detail.

Let us first look at costs that an earlier note also dwelt upon. Warehouses were indeed established for their 'inventory holding' functions. Streamlining operations and increasing productivity are therefore the primary cost-optimization drivers. However, in addition to squeezing costs and realizing savings, organizations now need to start looking beyond the four walls of their DCs. They must evaluate the cost of their network design and accelerate the physical consolidation of their distribution centers. They must also rationalize facilities costs and undertake periodic layout-optimizing initiatives.

Revenue-enabling functions too must change. Customers today expect wider choice. Fulfillment cycles have accelerated. Mobile devices are influential demand drivers. All these necessitate a larger role for DCs - including the expansion of the SKU-mix and 'buy-anywhere-fulfill-anywhere' paradigms. Delivered In-Full, On-Time (DIFOT) will remain a key enabler of customer satisfaction and retention. DCs need to facilitate faster returns and extend differentiating value-added services. In addition, they must constantly streamline operations, simplify processes, facilitate automation, extend visibility, and increase agility as they move up the value chain. Complete alignment of warehouse functions with channel requirements and consumer demand is the way forward.

Quite frankly, none of this is new. Yet less-than-optimal approaches to warehouse operations and warehouse management systems manifest into the very challenges outlined in the opening examples. In subsequent posts, we will look at some of the solutions presented here and their implications to warehouse management systems. Stay tuned. 

Until then, I would love your opinion on some of these questions. Do you sense sufficient awareness within organizations about the dichotomy between their assumptions of and expectations from a warehouse? Are change management programs applied holistically? To what extent is the alignment of customer, channel & warehouse complete within organizations? I would appreciate your feedback.

Posted by Arun Kumar at 2:00 AM | Permalink | Comments (0) | TrackBacks (0)

Lots have been said and written on this topic by various authors in various forums- including in this forum. Will ERP gobble-up EAM market completely in next 5 years? Where does PLM stop and ERP begin in enterprise architecture? Which of these is more functionally rich for asset intensive industry? The debate goes on and on.

The question I would like to put forth here is - Are these debates relevant anymore? In other words, how relevant is this debate to the end-user of these applications?

Having been on the both sides of the spectrum -as a seller & consumer of IT services, I would like to bring a different perspective to this topic. I believe all these comparisons are mostly creation of application vendors scrambling for a space (and to differentiate their product) in the crowded Enterprise Application market.

 
For the end-consumer on the floor, these are just software packages. They will go for that package which will make their life simpler- which will result in minimal disruption to their normal operations and are easy to use. I wonder how many of them really care if the UI (User Interface) they are working on is called an ERP or EAM or by any other acronym.
In my experience, I have seen that when it comes to choosing the enterprise applications, the ultimate decision makers are the business (users). The IT teams, in most of the organizations, at best, are just executioners of the IT strategy. The budget comes from business and therefore they make the final call- irrespective of their competency to do that. Consequently, the success or failure of any IT initiative largely depends on the muscle-power of the business-sponsor, who leads the initiative from business side. In reality, the functional richness of the application plays only a secondary role in determining the adoption levels or implementation success.
Many of the enterprise applications that I have seen implemented are only sub-optimally used. In some of the cases, hardly 20-30% of the available features are put to use. The scope of usage, strangely, is determined by how much the business sponsor "understood" the application features, more than any other considerations.

Bottom line- no matter how enterprise application designer has packaged the software with rich functionalities, no matter whether the application is called ERP or EAM or any other 3 letter acronym, the success of an implementation comes from how well the change is managed and how easy is the application to use.

I know that not everyone is going to agree to this point of view and this is going to raise few eyebrows. Keen to hear other perspectives.

Posted by C. N. Sajit Kumar at 10:45 AM | Permalink | Comments (4) | TrackBacks (0)

Recently we were evaluating various sourcing systems and with varied discussions among the attendees enchanted me to pen down this blog.
Sourcing has become a very crucial process in a procurement life cycle, for a purchaser the organizations goals and direction should be set for placing to determine which services should be handled by others and what to look for in a service provider. These are some the important aspects aligned to the company's purchasing policy, now the question here is using the right tool for your suppliers and the organizations but from an organizational point of view the key goals should be clear enough to justify the coverage of all business requirements from a procurement standpoint.

      The key domains that needs to be focused to have a sourcing system beneficial to customers following are important points
1) Defining a clear business objective for global strategic sourcing is a  premeditated move as it determines the savings potential from a convincing business case
2) Understanding the culture through research is critical as closing a deal with misunderstandings will not be beneficial and secondly if you understand cultural differences, you might be able to be more demanding of a supplier in another country than you would be in your own country
3) Landed Cost Model in global strategic sourcing, there are more cost components compared to domestic sourcing. A landed cost model helps you include global sourcing cost components such as multi-modal freight, duties, customs fees, and more into your analysis.
4) Defining Incoterms is the responsibility for the buyer and seller in terms of handling and paying for customs and shipping. They also define where the risk of loss transfers between the seller and the buyer
5) A Transportation Time Chart will help the proximity of suppliers influencing transportation times, which influences the inventory strategy. Always know your transportation times.
6) Accurate master Data:  All materials both direct and indirect should have material codes created. Any new material to be procured must have material code. This will benefit in reduced sourcing time next time and also give ready data about cost and   delivery time and competent suppliers in the market. Sourcing system should take care to have clear reports about material history.
7) Clear rules about self service procurement: sourcing system should be competent enough for   getting low cost material procured by user itself without   involvement of buyers. Sourcing system  must  be competent enough to have  internal catalogues, External catalogs and  process and document flow should be  smooth  through  these interfaces.
8) Sourcing system  must comprise   bid invitation,  auctioning  and  there must be   proper linkage from  raising a requirement to calling quotations to auctions to procurement and till payment to supplier.   RFQ nature must comprise  Public and restricated RFQ's and facility of  publishing  open RFQ's to  company website  so that  interested suppliers can look into it. This will increase  supplier base and good  negotiation  abilities.
9) Auction  portal  must be in  available technology in the market.  All suppliers should be able to  participitate  without  any technical issue.
10) Auction portal  must be  more flexible to  configure  and satisfy  customers  requirement.  For eg.   There are many clients  which demand auction on  header price and  also need restrication  for  content on display data  to supplier during auctioning. Also auction portal  must be  more flaexible to  configure additional changes  if  customer want additional fields  to be displayed.
11)  Timing issue  is critical for  auctioning. Sourcing system  must  have database timing and user timing  in sync.  Also  for users   located in different countries  must have flexibility to bid  in their  currency.
12) Sourcing system  must comprise suppliers as  their  part.  Suppliers  should be able to see their required reports, open RFQ's, upcoming auctions, existing PO's, PO details comprising GR's and invoices and Payment status.
13)  Data flow  between supplier  system  and  user system should be smooth  with inbuilt checks like quantity limit, value limit. This will reduce  support \ maintenance cost of application.

      These are some of the major focus areas that every Sourcing system should comprise, which would be beneficial to procurement managers

Posted by Nilesh Dhoble at 6:35 AM | Permalink | Comments (0) | TrackBacks (0)

The basic premise for any Forecast Model is that a pattern or relationship exists with regards to the variable being forecasted and that this pattern or relationship does not change over time. Thus the model that 'BEST' fits the available historical data will also be the best model to predict beyond these data points in the future. I will extend this further in the context of Forecast Models available in the advanced planning systems - The model that 'BEST' fits the 'historical data in the initialization horizon' will be the best model to predict beyond these data points in the future.
However in real life situations, as mentioned in my earlier blog, these assumptions do not hold true as these patterns or relationships are mixed with random noise or could change over time. The change in the pattern could be triggered either due to shifts in attitudes or behaviors of Consumers or caused by actions taken by Competitors or planners or due to a major technological breakthrough. The impact of these changes on the demand pattern depends on the elasticity of the demand being forecasted. With the Product Lifecycles getting shorter and the pace of new products introduced increased, the time a part would continue in a lifecycle is way less than the typical Historical or Forecast Horizons. In the High-Tech industry, we could encounter 3-4 Lifecycle stages, with completely consumption patterns in a planning horizon.

We do implement various Forecast Accuracy measures to generate alerts and exceptions when the thresholds are exceeded. However, it is noteworthy to consider the fact that a Forecast Model that is best for a particular demand pattern, need not be the best for a different demand pattern and there may be a better Forecast Model for the changed demand pattern that will not be chosen until the Forecast Accuracy of the current model do not exceed the threshold. This approach, although very effective when the patterns are stable, results in a reactive approach to managing changes in demand patterns, with the risk that some subtle demand patterns may just go unnoticed.

What we need is a more proactive approach towards monitoring structural shifts in demand patterns and hence this mandates a mechanism for monitoring patterns and relationships that provide timely alerts for any significant non-random change/shift in the pattern being forecasted. One of the most effective and widely used mechanisms is the Tracking signal, where we look at the forecast generation process through the lens of Quality Control. When the value of Tracking Signal is close to zero, we can conclude that the errors are random and that no non-random change has occurred. The value for Tracking Signal will continually increase, as the forecast errors consistently are either positive or negative. Once the predetermined threshold level is reached, we can conclude that the fluctuations are no longer random and a significant shift has occurred, resulting in a need to review the applicability of the Forecast Model assigned to the data pattern. Once the Forecast Models are reviewed and the new Forecast Model assigned, the values for Forecast Error must be set to Zero. Else, Tracking Signal will continue to be outside the control limits.

One of the key considerations is the definition of these control limits to ensure that any significant non-random changes are highlighted at the earliest, but at the same time the number of false alarms are minimized as this would result in time wasted for the Planner.
To enable automatic tracking for these changes, one of the most widely used approach is the 'Smoothed-Error Tracking Signal' which also happens to have minimum requirements of data maintenance and is very easy to understand. We can use standard APO Macros to implement the formulae to compute the Tracking Signal. These macros could be executed as part of the regular batch Forecast Cycle and would readily serve as a key exception/alert to the management to guide through the parts to be reviewed for any significant shifts in demand pattern.

SAP has introduced a new feature for their Forecast Models based on exponential smoothing in their latest release, SAP SCM 7.0 to reinitialize the model when a structural interruption or a major change in trend in the historical data is detected. The system would recalculate the Forecast parameters Basic Value, Trend Value and Seasonal indices, if there were enough data points available to determine these parameters. If there were not enough historical data points available, the system would provide the different options to compute the new forecast value. With the Tracking Signal touching/exceeding 2, the system would detect a structural shift and trigger a reinitialization of the Forecast parameters. This is a significant improvement from the current release, where the model parameters would be determined in the initialization horizon and the same would then be applied in the Ex-post forecast and the actual Forecast Horizon.

In my recent discussion with one of our clients who uses SAP APO extensively to plan for the service/customer care arm of the business, this new feature was seen as a significant positive step in monitoring of Forecasts. The Key forecaster in the client organization came up with a huge list of scenarios, where this new feature could add value. The key here was that the service lifecycle is much longer than the product lifecycle and hence the different phases in the service lifecycle need to be identified correctly to automatically trigger the system to use the right forecast model with the right parameters. The system must be able to detect changes in trends and accordingly adapt the Forecast models and parameters therefore. This new feature is already expected to bring about productivity improvements by eliminating the need for Forecasters to manually review the demand data for every part and location combination to detect such structural shifts and the Forecasting team in the client organization is more than eager to get their hands around this new functionality to be able to leverage on the automatic Forecast monitoring functionality by computing Tracking Signal. I would like to hear on your experiences with the use of this automatic forecast monitoring mechanism in the new SAP SCM 7.0.

Posted by Sandeep Deolekar at 7:57 AM | Permalink | Comments (0) | TrackBacks (0)