Category Archives: Procurement Damnation

Technology Sustentation 80: The Cloud

As SI said in our post on technology damnation 80, software was good. Hosted ASP was better. True multi-tenant SaaS was better still. But the “cloud” is, more often than not, the one step back that follows the two-steps forward.

The cloud is not a white fluffy cloud full of day dreams, it is a gathering storm cloud that could soon erupt and flood your entire operation while the hail it dispenses pummels you to a bloody pulp.

As per our damnation post, if you are not careful, you could:

  • lose your mail,
  • lose your data,
  • lose your platform, and
  • lose your customers as well as
  • lose your supply chain visibility,
  • lose your revenue stream, and
  • lose all the cash in your bank account

And you could be permanently lost at sea when the floods carry you away.

Unless, of course, you take precautions. What kind of precautions? Every kind of precaution you can take. But at a minimum:

  1. Make sure that your providers’ platforms are designed in such a way that not only is there no data cross-pollination, but that there is no access cross-pollination. This may require that the provider not only create a new instance for each client, but run it on a new virtual machine. (The database can be on one server, as long as it’s encrypted and the encryption for each client uses a unique key so that if a hacker gets through to the database through another client’s poor security configuration, and gets all the data for that client, your data can’t be decrypted.)
  2. Make sure that the provider supports encryption across all of your data, not just parts of it, and that it is up to date (and up to snuff). Even data that might be considered inconsequential can be enough to be damaging if enough bits of it are pieced together.
  3. Make sure the provider does near-real time incremental, replicated, distributed, off-site back-ups to make sure that, in the case of hardware failure (or FBI/NSA server seizure), your data is not lost.
  4. Make sure the provider has multiple real-world data centres that the platform can be run on in case one (or more) data centres become unavailable.
  5. Make sure the provider has a distributed fault-tolerant up-time monitoring solution that can detect if an application instance becomes unavailable and restore the most recent back-up to a different data centre and do the necessary re-routings in (near) real time.

In other words, security, fault-tolerance, and distributed processing and back-up are critical. Without it, you’ll be hacked, your system will go down, and you may not get it (or even your data) back.

Procurement Sustentation 11: Postal Services

As per our infrastructure damnation post on Postal Services, public postal services, even though not widely used by most large enterprises, are necessary to prevent private monopolies and to force the private enterprises to be more competitive than they would otherwise have to be.

More importantly, they are often vital for large retailers that depend on direct to consumer sales (and shipping) as, sometimes, public sector service prices (for large retailers who cut good deals) are better than private sector prices, and just as quick (as many postal services have enough carriers to cover every door 5 days a week without having to add staff or miss promised delivery dates in peak seasons).

But the costs might skyrocket as many postal services go deeper and deeper into the red, and look to stabilize themselves through increased package costs (and USPS rates recently went up rather significantly in the US for parcels), and those retailers not ready for this may find themselves losing customers hand over fists who balk at shipping prices that dwarf the costs of the products they are buying. Even if the retailer has the volume to negotiate only a slight increase, any increase can be devastating.

So what can a retailer do?

The first thing it needs to do is try to lock in long term price agreements with the public sector postal services it is dependent on. That way, if prices do rapidly rise, it has the time to negotiate the best deal it can with private carriers if it has to go the private route.

The next thing it needs to do is start negotiating with multiple private carriers that can handle its volumes and try to negotiate deals as good as it has in the private sector and switch about half of it’s volume to the private carrier who wins. That way it has both options, and can even switch back to the public sector if the private sector option because more costly or risky.

Finally, it has to explore in-store or near-store pick-up options. For example, Amazon is exploring locker pick-up in urban locations that can be as fast, or faster, than direct-to-door shipping, and cheaper too. Multi-channel delivery options are the key to perpetual success.

Technology Sustentation 75: Mobile Movement (Madness)

The mobile movement, as we pointed out in technology damnation 75, is as much of a curse as it is a blessing. As we noted in our post:

  • you will be expected to work anywhere, anytime;
  • data entry will be painful as small screens, and smaller keyboards made for real mice, will be the norm (and you can thank Apple and their new mini 4″ iPhone); and
  • task time will triple as small, limited power processors, chug, chug, chug trying to deal with media-heavy websites and bloated data transfer protocols despite the fact that
  • suppliers and customers will expect a whole new level of relationship management

So what can you do?

  • define your relationship management processes and protocols and make sure new suppliers and customers know, day one, what they can expect and the level, and kind, of service you will provide
  • limit the amount of functionality that your applications will support on a mobile device to needed functionality
  • make sure mobile applications and devices support scanning/sensor reading as much as possible (bar codes, QR codes, RFID chips, etc.); manual data entry should be web-based OCR (image, upload for server processing, user override, save); etc.
  • make sure support channels are well defined so that only people who are working or on call get contacted when requests come in — don’t automatically route a non-critical support call to the primary rep at 3 am in the morning when a secondary support rep is on call half a world away at 3 pm in the afternoon (VOIP is a wonderful thing)

We’re stuck with these devices whether we like ’em or not, so let’s make sure we design for them appropriately and work-life boundaries are properly set, otherwise, we’ll all be asking:

Can I Play With Madness?

Provider Sustentation 69: 3PL Firms

Just like 3PL firms were the first provider damnation we covered, they are also the first provider sustentation we are going to cover. For many under-staffed, under-supported, and under-platformed logistics departments, 3PLs are a blessing because, without sufficient staff to analyze options or modern technology platforms to crunch the numbers, 3PLs offer the organization an instant cost savings, a substantial time savings, flexibility, and, presumably, focus. But, as we said, these advantages are there for a reason — to cloud the disadvantages that 3PLs also bring. 3PLs are a true double-edged sword that, depending on the angle you see it from, shines as bright as the sun or drowns you in the darkest night of the abyss.

As we clearly said in our damnation post, in exchange for:

  • cost savings, the organization gets IT headaches
  • flexibility, the organization gets a loss of visibility
  • focus, the organization gets a complete loss of control

Why?

  • the 3PL uses its own TMS, and doesn’t give a damn whether or not it integrates with any of your systems
  • the 3PL contracts the carriers, and if it the carrier gives you sucky service, too bad as you’re stuck with them until the contract is over (which could be a while if it services the 3PL’s bigger clients good)
  • the 3PL manages the carriers it contracts, the lanes they take, the cross-docks they use, and so on and as a result your visibility into where your stuff is at might be limited to expected ship date, current status, and expected delivery date

But all is not lost. If you properly pre-qualify, properly pre-nup, and properly (pre-)define the commitments, you might only see the bright and shiny side of the double-edged sword — the side that cuts through your problems and leaves only cost savings, flexibility, and focus in its weight. Of course, to do this, you have to make sure that:

  • during the pre-qualification phase you
    • be sure to dig-deep into the TMS, out-of-the-box integration support, data import/export options, and timelines for custom integration
    • be sure to ask a lot of questions about standard carrier contracts, common carriers, selection process, and the input you can have over it
  • during the proposal phase you
    • make sure the provider gives commitments on system integration timelines, carrier selection process, issue response and resolution times, and support availability
    • make sure the 3PL provides active references of a similar size, proof of necessary insurance or regulatory approvals, and other documentation that will be needed upon signing
  • during the final contract pre-nup phase you
    • make sure the carrier agrees to penalties if integration dates are missed, deliverables are late, or promised performance never materializes
    • make sure the organization can back out if problems persist or go beyond a certain point of severity

As we said before, the right 3PL, that is properly selected, agrees, and adheres to the right terms and conditions, will be a lifesaver for many companies, but the wrong one could bring the organization to its knees. So it’s critical to select the right 3PL.

Technology Sustentation 80: The Cloud

As SI said in our post on technology damnation 80, software was good. Hosted ASP was better. True multi-tenant SaaS was better still. But the “cloud” is, more often than not, the one step back that follows the two-steps forward.

The cloud is not a white fluffy cloud full of day dreams, it is a gathering storm cloud that could soon erupt and flood your entire operation while the hail it dispenses pummels you to a bloody pulp.

As per our damnation post, if you are not careful, you could:

  • lose your mail,
  • lose your data,
  • lose your platform, and
  • lose your customers as well as
  • lose your supply chain visibility,
  • lose your revenue stream, and
  • lose all the cash in your bank account

And you could be permanently lost at sea when the floods carry you away.

Unless, of course, you take precautions. What kind of precautions?

  1. Make sure that your providers’ platforms are designed in such a way that not only is there no data cross-pollination, but that there is no access cross-pollination. This may require that the provider not only create a new instance for each client, but run it on a new virtual machine. (The database can be on one server, as long as it’s encrypted and the encryption for each client uses a unique key so that if a hacker gets through to the database through another client’s poor security configuration, and gets all the data, your data can’t be decrypted.)
  2. Make sure that the provider supports encryption across all of your data, not just parts of it, and that it is up to date (and up to snuff). Even data that might be considered inconsequential can be enough to be damaging if enough bits of it are pieced together.
  3. Make sure the provider does near-real time incremental, replicated, distributed, off-site back-ups to make sure that, in the case of hardware failure (or FBI/NSA server seizure), your data is not lost.
  4. Make sure the provider has multiple real-world data centres that the platform can be run on in case one (or more) data centres become unavailable.
  5. Make sure the provider has a distributed fault-tolerant up-time monitoring solution that can detect if an application instance becomes unavailable and restore the most recent back-up to a different data centre and do the necessary re-routings in (near) real time.

In other words, security, fault-tolerance, and distributed processing and back-up are critical. Without it, you’ll be hacked, your system will go down, and you may not get it (or even your data) back.