Category Archives: Technology

What Elements Are Truly Necessary To Prevent Missing Links in Your Supply Chain?

A recent article in Canadian Transportation & Logistics that asked “where the missing links in your supply chain are” did a great job of of pointing out that when it comes to supply chains, what you see is what you get. And it often is the situation that the more you can see into the chain, the more benefits you can receive.

It also hit the nail on the head when it noted that the ability to view timely, accurate information from the beginning of the chain to the end is essential for:

  • reliable forecasting
  • accurate decision making
  • minimizing risks
  • optimizing inventory turnover
  • reducing days and costs in supply chain cycles
  • healthy cash flow and profits
  • customer satisfaction
  • competitive advantage

But when most companies rely on a patchwork of systems and software to address supplier management, purchase order processing, receipt of goods and inventory management, did it have the right checklist of critical system and software capabilities required to avoid the critical missing links that are currently present in most enterprises that are not Supply Management Leaders?

The article identified these necessary elements, which we’ll take one by one:

  • Real-time detailed visibility into every key juncture
    i.e. demand, procurement, production, transportation, and inventory and accounts payable (to make sure the invoices match the order), market data (to make sure quotes are reasonable), risk data (to detect potential volatility or issues as soon as the signals appear), and trade data (to inform you on issues of regulatory and customs compliance)
  • portals connecting the entire supply chain from order through deliver
    what year is this? 2002? there has to be e-integration all the way down through you supplier, and their suppliers, to raw material providers for key or scarce raw materials, but it doesn’t have to be a portal; heck, it could be as simple as the pull of a daily update EDI file from a secure FTP server or as complex as real-time asynchronous communication between multiple databases in a replication configuration
  • collaboration capabilities that allow stakeholders of the chain to readily share information on supply and delivery
    and communicate with each other, in real time, when they are both online
  • ability to integrate varying information formats from various supply chain partners
    which is a given and should be automatic; again, it’s 2012, not 2002
  • open-endedness with flexibility
    enabling easy modifications and integration with other systems and this is a definite must — avoid any system with proprietary integration methods
  • capability of generating alerts of events that require attention
    throughout the supply chain as most day-to-day management should be exception based, with the exceptions defined on your rules (and not the vendor’s)
  • ability to create “dashboards” that enable consolidate viewing of information from multiple sources
    in a manner that focuses on problem areas identified by missed metrics, bad data, missed data, or declining trends — generally speaking, you don’t care about the green, only the red

These were quite good, but it’s also very important not to overlook:

  • sourcing, procurement, logistics, and global trade solutions
    this could be one solution with dedicated sourcing, procurement, logistics, and global trade modules (or views) or multiple solutions that are interconnected — you need end-to-end sourcing to identify the right deal, procurement to secure it, logistics to get it delivered on target, and global trade to make sure there are no costly, disruptive snags
  • an analytic solution
    that lets you analyze trends and predict demand levels, market cost changes, and potential disruptions
  • out of the box ERP support
    because chances are that a number of supply chain partners are going to have one of the big ERP solutions and be relying on it at least partially
  • security
    as there will be a lot of sensitive data flowing back and forth — make sure it is encrpted and only accessible by authorized parties
  • adoption
    how many companies are currently using the solution, how big are they, how much third party support is there and what is the long term outlook for the solution

But if you can meet all of these requrements, and the collaboration flows, the the solution is probably going to prevent many of the critical missing links in many of today’s supply chains.

SAP bought Ariba. What Should You Do?

 

Don't Panic

 

With one hand, pick up your copy of The Hitchhiker’s Guide to the Galaxy, with your other hand grab a Pan Galactic Gargle Blaster, have a seat, and read a few random entries while you have a nice relaxing drink. And definitely don’t panic.

In fact, don’t even give the acquisition a second thought right now. Why? Despite what every e-Procurement, e-Sourcing, and Supplier Network vendor seems to be implying with their comments (as summarized by Peter Smith over on Spend Matters Europe), press releases, etc., the reality of the situation is that, for the time being, nothing is going to change and you don’t have anything to worry about.

Since no one else is going to spell it out for you, the doctor is.

  • Ariba was the largest pure-play vendor in the Sourcing/Procurement space
  • SAP is one of the largest ERP vendors in the space
  • Large Companies are slow moving
  • Large Companies have high overheads
    (and can’t afford to sacrifice revenue streams without replacements)
  • SAP has a Fusion road-map through 2020

When you put all this together, and consider what has happened with past acquisitions in both companies, the following picture quickly emerges:

  • SAP is going to slowly merge Ariba products into its suite(s) through Fusion
    but this is going to take years and in the meantime
  • SAP is going to continue to sell and support Ariba as-is in the interim
    because it needs to not only make its money back, but support the high overheads until it is in a position to absorb Ariba into it’s core platform and do away with needing to maintain a separate suite.

In other words, you have a few years to come up with a backup plan if the way SAP merges Ariba’s suite into their platform isn’t to your liking or if the renewal costs when it happens are too rich for your blood. The only people who need to panic now are SAP partners where a significant percentage of their business came from SAP referrals as SAP will no longer be referring anyone with Sourcing, Procurement, or Supplier Network needs to third parties. (Companies like Hubwoo might be in this boat.)

Now, depending on where you are in terms of a renewal, or how much data you have in the system, or how much you use the system, you might not want to wait a few years to start thinking about moving off of the platform if you are worried about it meeting your future needs, but you don’t have to rush into a decision. And you certainly don’t have to panic. Time is on your side.

What is Visibility?

Supply Chain Visibility is a hot-topic, and, as reported in this article in Logistics Management on Defining Visibility late last summer, was the hottest project in 2011 according to a Capgemini Consulting study. Fast forward to 2012, and visibility is a term I’m hearing from at least every other vendor as a selling point of their supply chain services and solutions.

Thus, at this point, I have to ask — what, pray tell, is visibility? When we look up visibility, the first definition returned from dictionary(.com) is the state or fact of being visible, which isn’t very useful since visible is defined as that [which] can be seen. So what do we have to see?

Well, if you talk to a software-based solutions vendor, we have to see the data. Specifically, data on where your order is in terms of production, shipment, or delivery. And this is good, but it’s not enough. While this will tell you that production on an order is three (3) days behind, it won’t tell you why. Is the plant recovering from a backlog, and about to put your order into overtime production tomorrow? Are they suffering from a worker shortage, or strike, and your order is delayed another week? Or have the components and/or raw materials not yet arrived? And if it’s the latter situation, why? Is it a transportation delay? A production delay? Or a raw material shortage that may take months to correct? So you need visibility into the status of your order and all of your supplier’s orders that impact your orders. But this isn’t always enough.

While it would be great to know as soon as a delay occurs that could potentially impact your supply chain, and give you more time to respond and potentially create and/or implement mitigations and counter-measures (such as finding an alternate source of supply or stepping in to help the supplier solve the problem), this still doesn’t give you any indication of problems that could be brewing. That’s why other vendors try to sell you risk-focussed data solutions such as financial viability reports (from credit-based data) and activity reports (from import/export data). But these solutions only allow you to judge supplier viability, they don’t allow you to determine if an external event in the supplier’s locale (such as war breaking out or a likely natural disaster) could take the supplier out even if they are financially viable and low-risk from a business perspective. So other solutions try to sell you country-based risk assessment solutions with data on each of the locales you are doing business with. And this is a type of visibility. As are sustainability tracking solutions which track sustainability data (with regards to environmental, legislative, and other types of compliance data) to try and predict current and future supplier health based upon a sustainability score that goes beyond pure financial data. And this is another type of visibility.

And if you had all these solutions, you could certainly argue that you had supply chain visibility, but the question is, how complete is it? How much do you need to see to be confident that the chances of an unpredicted event are sufficiently low and/or the chances of you not knowing about an unpredictable event soon enough to implement mitigations are sufficiently low? It’s hard to say. It probably depends upon your operation, your risk exposure, and the strength of your supply chain and supplier relationships.

Regardless, visibility is a concept that is hard to narrow down and no one approach completely solves the problem. Keep that in mind when evaluating solutions on the strength of their visibility.

No Interface, No Delay?

Apparently, according to a recent article in Inbound Logistics that proclaimed All In One, a good reason for buying an integrated ERP / SCM solution is the fact that if the solutions are integrated, then there is no interface between two separate systems that could cause problems or delays. An interface is another piece of software that, like the ERP / SCM solution, could have its own set of issues. And it’s another piece of software that has to be maintained.

However, this applies to integrated systems as well. Most integrated systems are composed of multiple modules, each of which has their own interface. As a result, the no interface, no delay argument doesn’t have a lot of merit. If there’s a bug in the internal API, then there could be a system failure in the sole-source system just as easy as there could be a system failure in an interface or a third party system.

The proper rationale for selecting an integrated solution is because it:

  • has all of the key features that are required,
  • meets the needs of the organizations and the users,
  • and brings the right value to the organization.

You don’t select an integrated solution because it:

  • is cheaper,
  • minimizes the number of suppliers you need to interact with,
  • or minimizes interfaces.

It’s not about cost, it’s about value. It’s not about supplier count, but what the suppliers can bring to the table. And it’s definitely not about the number of interfaces, but about the stability of the interfaces and whether or not they enable access to the right data. The short story is that you can make arguments for and against either solution, but it all comes down to the merits of the solution with respect to your organizational needs, not a generic pro/con checklist.

How Much Does That Enterprise Supply Management Solution Really Cost, Part II?

In yesterday’s post, we asked how much an enterprise supply management solution really costs because the up-front license cost or annual subscription fee is only one part of the puzzle — and until the full puzzle is understood, it’s hard to figure out what the true cost is and, ultimately, what’s the right solution for the organization. The difficulty is the plethora of license models, and add-on fees, that have been invented by on-premise and SaaS/Cloud vendors over the years in an effort to get a leg-up on their competition (and a siphon into your corporate piggy bank). In today’s post, we’re going to review three proposals from three vendors, Siphon, Skimmer, and Drip. Then, we’re going to demonstrate how to compare them on equal footing.

Siphon is proposing an on-site enterprise solution with a perpetual license cost of 50K plus 100 per user, an implementation fee of 20K, an up front customization fee of 15K for reporting, 25% maintenance, and up-front training of 10K for administrators and 20K for users. It also requires a database, application server, and a middleware license — which have their own maintenance fees. It also requires (3) servers to host the product, space in the data centre, an administrator / developer to maintain the customizations, and a user support person.

Skimmer is proposing a hosted ASP solution with a perpetual license cost of 50K, an additional fee of 50 per user, an additional fee of 1K per integration, and a small transaction fee of $1 per transaction. Maintenance is 10%, but the initial implementation cost is 40K, not counting the 20K for custom reporting or 20K for integration with external systems. User training is 20K up-front.

Drip wants to go pure multi-tenant SaaS for a hosting fee of 40K a year, with 30K up front for implementation, 20K up front for custom reporting, 10K for external systems integration, and 20K up front for training. However, ongoing training, largely self-led, is minimal at 5K / year.

On the surface, Drip sounds expensive if you’re looking to make a 5-year commitment because it’s 200K in license fees, as opposed to 50K for Siphon and 50K for Skimmer, but Skimmer has over 100K in additional up front costs (bringing your down-payment to 150K) and Siphon has at least 75K of up front implementation costs (bringing the total to 125K) plus whatever it costs for the database, app server, and middleware.

The only way to really understand what the respective costs are is to build a detailed cost model that allows for an apples to oranges to pears comparison that allows for similar elements to be compared on an equal footing when possible, and total cost to be understood.

To this end, you need to build a cost matrix similar to the one below (which is contained in this free cost model spreadsheet [that you can use at your own risk*]) so that you can determine the true cost of the solution over the time-span you expect to use it. (Be it the 1, 3, 5, 7, and 10 year time-frames pre-calculated, or some other time-frame). Then fill in the gaps.

For starters, with respect to Siphon’s proposal, we have to cost out the database, application server, and middleware. When we do that, we find that the db license is 15K plus 30% annual maintenance, the application server is 10K plus 25% maintenance, and the middleware server is 20K plus 20% maintenance. Plus, we need to buy 3 servers to support it — one for the application and middleware, one for the database, and one for the web application server. Digging deeper, we find out that it needs five custom module integrations, and each will cost 2K, tacking another 10K onto the proposal in addition to the 10K required to integrate with external systems. Digging into the support requirements, it’s going to require 50% of an admin’s time, and that person costs 90K a year, and 100% of a support rep’s time, and that person costs 60K a year. The servers will consume about 6K of power, an additional 3K of backup services will be required, and the annual maintenance on the database, middleware, and app server will cost 5K, in addition to 5K of annual training to keep the admin up to date.

Skimmer, being a hosted ASP solution, also requires an annual hosting fee of 20K for data centre costs in addition to the 50K perpetual license cost, and an additional fee of 10K in each subsequent year for training.

Drip, being a pure multi-tenant SaaS, has no other costs.

When we put it all together, we end up with the table below:

Cost
Components
On-Premisee Hosted ASPP SaaS
Perpetual License (K)
Flat Fee 50 50 0
Per User 0.1 0
# Users 100 0
Per Module 0 0
# Modules 5 0
Per Integration 2 0
# Integrations 5 0
Per Server 0 0
# Servers 3 0
Total 70 50 0
Annual Hosting Fee (K)
Base Fee 0 20 40
Per User 0 0.05
# Users 0 100
Per Module 0 0
# Modules 0 5
Per Integration 0 1
# Integrations 0 5
Per CPU Hours 0 0
# CPUs 0 0
Per Transaction 0 0.001
# Transactions 0 300
Total 0 30.3 40
Maintenance % (0-1) 0.25 0.1 0
Equipment Up Front
Server Count 3 0 0
Server Cost (K) 8 0 0
Server Life-Span (Yrs) 3 0 0
Total 24 0 0
Mandatory Software
Perpetual DB License (K) 15 0 0
DB Maintenance % 0.3 0 0
Perpetual App Srvr License (K) 10 0 0
App Srvr Maintenance % 0.25 0 0
Perpetual Middleware License (K) 20 0 0
Middleware Srvr Maintenance % 0.2 0 0
Total Software (K) 45 0 0
Total Maintenance (K) 11 0 0
Implementation Cost (K) 20 40 30
Ext. Sys. Integration (K) 10 20 10
Custom Report Development (K) 15 20 20
Upfront User Training (K) 20 20 20
Ongoing Training (Yearly) (K) 10 10 5
Data Center Costs
Admins/Developers Rqrd 0.5 0 0
Annual Salary (K) 90 0 0
Support Reps 1 0 0
Annual Salary (K) 60 0 0
Power (K) 6 0 0
Integrated Systems Maintenance (K) 5 0 0
Backup Fees (K) 3 0 0
Ongoing IT Support Training (K) 5 0 0
Total 124 0 0

And then when we summarize the costs, breaking them down into first year and subsequent year, we get the following summaries:

Up-Front
First Year Costs
On-Premise Hosted ASP SaaS
Perpetual License 70 50 0
Equipment (Computer) 24 0 0
Mandatory Software 45 0 0
Base Implementation 20 40 30
Ext. Sys. Integration(s) 10 20 10
Custom Reporting 15 20 20
User Training 20 20 20
Year 1 Data Centre 124 0 0
Year 1 Hosting/Subscription 0 30.3 30
Total Up-Front 328 180 110
Ongoing Yearly Operating Costs On-Premise Hosted ASP SaaS
Hosting/Subscription 0 30.3 40
Maintenance Fees 17.5 5 0
Mandatory
Maintenance Fees
11 0 0
Equipment Upgrades 8 0 0
On-going Training 10 10 5
Data Centre Costs 124 0 0
Total Yearly 170.5 45.3 45

And then we quickly see that, in the first year, SaaS is the cheapest and On-Premise the most expensive and, more importantly, that going forward, On-Premise is considerably more expensive due to high data centre costs. We also see that, overall, SaaS will be the cheapest solution but this doesn’t mean it is the right solution as the cost of Hosted ASP and SaaS in subsequent years is almost the same, and if the Hosted ASP provider can offer substantially greater security and reliability with the single instance they are offering (as opposed to the multi-tenant SaaS solution), it might be worth the additional 70K up-front cost for the Hosted ASP solution — especially if the company is looking to commit for a longer term (like 5 years). Plus, With the costs so similar, a negotiation might be able to reduce the base implementation and integration costs, putting the Hosted ASP solution on par with the SaaS solution. However, none of this would be clear without this total cost calculation. So do your homework, and your detailed year-over-year costing, before selecting a solution. It will pay off.

* All warranties or representations, express or implied, are disclaimed and you take complete responsibility for the use, or misuse, of the template.