Author Archives: thedoctor

Top 10 words or phrases to ban from an RFP response, Part 1

In this two-part article we are going to give you the top 10 words or phrases you should ban from RFP responses if you want a meaningful response to your technology / technology-backed / technology assisted RFP that’s not full of meaningless buzzwords, ambiguity, misdirection, or some combination thereof. The simple fact of the matter is that if you allow any of these phrases, you are not getting an answer, or at least not an answer you need.

10. Savings

Let’s get straight to the point. “Savings” do not exist. Cost avoidance does exist, but if a sourcing event identifies “savings”, it doesn’t mean that you negotiated savings, it meant that you were overspending and that the event identified that overspend so you could make changes to your Procurement to prevent that overspend. That’s it. Savings is money the business accumulates over time. The other definition is finding a way to truly reduce the amount of time, material, or resources to make something — which is something that is up to your supplier to figure out, not you. Your job is to buy at the lowest cost + margin the vendor/service provider will sell for and avoid overspend. The only “savings” you can realize is in the amount of time a process takes (which is why you buy appropriate software platforms to minimize your effort) or the amount of resources a product takes (with a better design). That’s true savings.

9. Market Intelligence

This one absolutely drives the doctor crazy and it should drive you crazy too. WTF is “market intelligence”. The market is not intelligent. In fact, ever since the introduction of Reaganomics, predicated on the false belief that a rising tide floats all boats (as discussed in Why America Abandoned the Greatest Economy in History), one could argue that the market has become decidedly unintelligent (at the same time that American IQ’s have dropped as per a recent article on The Hill, which, of course, we all blame on X).

Now, they may promise better insight into market pricing (but what is that, especially if you can just buy a real-time data feed to commodity indices or public sector contract prices), market dynamics (but isn’t that just buy and sell data), inflation or cost changes (but that requires good predictive analytics, do they have that technology and do they know how to use it), and so on, but only true experts can really provide insight that is likely to come true. And do they have those experts? And what’s their historical accuracy? Most firms don’t have leading experts in the top 10%. Basic math says only 1 / 10 “experts” are in the top 10% and only 1 / 10 companies offering a “market intelligence” service are in the top 10. So ask exactly what information/advice they provide you, how they provide it, how often they update it, who in particular does any manual predictions, and so on.

8. Diversity

Diversity is important. It’s very important. It’s absolutely necessary if you need a supplier to come up with innovative solutions to a problem. But simply allowing a supplier to say they are diverse or check a “diversity” box doesn’t tell you anything. First of all, what’s their definition of diverse. One white woman on a board that otherwise is entirely composed of greedy old white men? Might make their definition of diverse, but definitely, definitely, definitely wouldn’t make the doctor‘s definition of diversity.

True diversity is men and women of all ethnicities, experiential backgrounds, educational backgrounds, and so on that are available to you in the areas in which you employ people. Especially those from diverse backgrounds divergent from your founders / management. And it’s not an arbitrary target, it’s representative of the average diversity in your area. As we have said before, saying you want 50% women in an IT or Engineering company when only 25% of graduates are women is not achievable (but 25% is).

7. Green Procurement

What does “green procurement” mean. the doctor bets you have a definition. And the doctor bets its probably bull crap. Not to say that your intentions, or goals, are bad, or that what you think it is is bad, but that how a less than scrupulous supplier will respond to it is bad. Because when it comes to “green”, there is an awful lot of “greenwashing”, “greenlighting”, “greenrinsing”, “greenhushing”, “greenshifting”, “greencrowding”, or other decidely ungreen practices out there, and if you’re not careful, a supplier will sell you one of these not-so-green services when you ask for a “green” solution. (And, in fact, you’d be greener if you simply asked Kermit the Frog to buy you some lettuce from the local farm. After all, no one knows better than Kermit that It’s Not Easy Being Green.)

6. Sustainable Procurement

What does this mean? It’s even more ambiguous than “green procurement”. Does it mean that what you are buying is sustainable, or does it mean that the process is sustainable. Technically, under the rules of English Grammar (you know, that system of language rules they don’t seem to teach anymore), “sustainable” is an adjective to the “procurement” noun that follows, so as long as the vendor/service provider supports your Procurement process in a way that is sustainable to you, they’ve technically met the requirement, right? Right! But what you want is sustainable goods and services, but that’s not technically what you asked and the sneaky slippery suppliers will try to use that ambiguity to give an ambiguous response and slip a bid in that you shouldn’t consider. So again, don’t ask if they have sustainable procurement, ask what efforts they make to use renewables, minimize resource (water, energy, non-renewable material) use, ensure their suppliers are using sustainable practices and financially sound, and so on.

In other words, buzzwords are not answers, and any provider that simply spews slang at you is not solving serious situations that are relevant to your business. So ban the buzzwords, get deep insight, and make the right decisions.

Of course, since we started at 10, these aren’t the worst of the buzzwords. Not the worst by far! In our next part, we’ll review the top 5. Stay tuned.

Ten Best Practices for (Software) Vendors, Part 6: Bonus Best Practice #3

If you need to catch up:

  • Part 1 Best Practices #1 to #3
  • Part 2 Best Practices #4 to #7
  • Part 3 Best Practices #8 to #10
  • Part 4 Bonus Best Practice #1
  • Part 5 Bonus Best Practice #2

This summer, during the dog days of summer, as a cure to the summertime blues, the doctor gave you ten best practices for success inspired by the common mistakes that the doctor has seen small/mid-sized vendors do over, and over, and over again for the past twenty years (and, more specifically, mistakes that are costing them deeply). And while the best practices linked above won’t necessarily solve all your problems, implementing all of them should prevent a number of major problems, or at least a number of the major problems that are common to multiple technology companies trying to developer and deliver deviceful delicacies to software shoppers.

We stopped at ten, and two significant bonus, tips because ten is the number talent likes to start with, and most of the other issues the doctor has seen repeatedly (that the tips were designed to address) were either a) less relevant or b) less common or occurred less often. However, every time we enter either an extended recession, or a tech downturn (symbolized by the top employers shedding tens of thousands of workers based on economic expectations and fear and not reality [despite bank accounts richer than some nations]), there is one mistake the doctor sees over and over again. Furthermore, this ONE mistake is very dangerous as it prevents some companies from fully recovering, and sometimes starts the downward fall to insolvency or forced (fire)sale to stay in business. To counter it, we give you Bonus Best Practice #3:

BUILD(UP) DURING A DOWNTURN

The biggest mistake the doctor sees over, and over, and over again during a downturn is pushing off (market) research, development, marketing, hires, and other activities necessary for growth until “sales pick up”. The problem is, in many of these smaller enterprises, they usually barely have the resources to support the current customer base and when “sales pick up”, there’s often not even enough manpower for the implementations, so development is stopped to redeploy developers to implementation in the short term; marketing is stopped as those resources are diverted to partnership development with consultancies and implementers; pre-sales support is diverted to account management; and so on. At the same time, the big companies — who can offer bigger salaries, hire faster, and bring more people on board — are planning for rapid hiring, marketing increases, and accelerated development as soon as the market starts to swing up again. They may not be hiring more, spending more on marketing, or augmenting the dev team, but as they have enough resources already, they are preparing to do this. As a result, when the market starts to ramp up, they’re ready to go full swing, be everywhere, demonstrate they are working on a new-and-improved roadmap, and address the major market concerns.

In order to grow as a small/mid-size operation, you need to fully capitalize on up-swings, and the only way to do that is to:

  • have marketing plans and content in place
  • have (pre-)sale position descriptions ready to go and outlets identified
  • have optimized implementation processes in place (so you can do more with less)
  • have partner training courses and support ready to go (so you can augment when you need to)
  • have identified the most critical features that companies want that you don’t have
  • have identified the most innovative/unique/valuable improvements you can start working on and sell as part of the roadmap
  • have done your market research so you can go head-to-head with the big boys who will be ready (and win without properly prepared competition)
  • and so on

AND THIS NEEDS TO BE DONE DURING THE DOWNTURN!

When the upswing starts, it’s too late. Even experienced experts can’t always move fast enough when your more forward thinking peers have been working on their plans in the background since the downswing started and are ready to hit the market full force, while you’re struggling to figure out what to do now that companies are spending again.

Now, the doctor understands that hiring can be an issue because you don’t know precisely when the upswing is going to begin, and if it only takes 3 months of work to get the marketing plan, content, and pre-sales artifacts in place, you don’t want to hire that person 6 months before the upswing. Or maybe it only takes 3 weeks to identify the right improvements to the platform to optimize the implementation process, and then your developers just need to do it. Maybe you only need partner support for training and services with an optimized implementation process, and that’s just completing put-off documentation which only takes a few months (until more platform capabilities are developed). And you don’t have to code features your customer base won’t be ready to use for another two years that take six months to build for another eighteen months, but you do have to know what they are, how long they will take, and how you will sell them. So timing is difficult.

But nowhere did the doctor say you had to hire! Just that you needed to prepare. And, as per Bonus Best Practice #1, Get the Help You Need, you can always hire a contractor or a consultant to get this done, and then, when the upswing starts, sales start coming in, and the marketing, research, product roadmap/management, (pre-)sales, and partner support needs become more intensive, then hire full-time on staff people once the workload for a specific function becomes almost full time.

In other words, the key to success is to get ready to get ‘er done, and get ready to get ‘er done NOW!

Source-to-Pay+ Part 7: Multi-Tier Risk

In Part 1 we noted that Risk Management went much beyond Supplier Risk, and the primitive Supplier “Risk” Management application that is bundled in many S2P suites. Then, in Part 2, we noted that there are risks in every supply chain entity; with the people and materials used; and with the locales they operate in. In Part 3 we moved onto an overview of Corporate Risk, in Part 4 we took on Third Party Risk (in Part 4A and Part 4B), in Part 5 we laid the foundation for Supply Chain Risk (Generic), and then in Part 6 we addressed a major supply chain risk: in-transport.

As part of (generic) supply chain risk, we highlighted multi-tier risks that arise when multiple suppliers need to process materials, make sub-components, build components from those sub-components, and then assemble those components to make your product. When it takes 10,000 suppliers to make your product (which is the case with some complex electronics products), the risks are beyond what most minds can comprehend. Multi-tier risk management systems for direct supply chains must address a number of specific requirements outlined in Part 5.

Capability Description
Connections & Relationships It is incredibly important to keep track of all of the connections in the supply chain, not just the links that represent the paths of raw materials from the source into the products that your tier 1 suppliers supply you. You need to know who else your suppliers supply, any risks that poses to you (if your competitors have more influence and can steer the direction, process, and quality of the supplier); who supplies your suppliers, any risk that poses to them, and thus to you; who owns your suppliers, and any risk that creates to your organization in different countries of operations due to sanction lists; and who your suppliers contract out too, and any risks that may pose.

It is thus critical that a multi-tier supply chain risk management solution support connection graphs that can be re-oriented around any entity at any time for a quick inspection of risks posed by that entity and all entities it may in turn affect. It is also critical that the solution support drill-in at each entity for deep insights and analysis.
Bill-of-Materials The platform must support multi-level bill of materials (BoM) support. You can’t track the full supply chain if you can’t track the full product inputs all the way down to the raw material inputs for each component, sub-component, and primary part. You also need to be able to trace any product with an issue down to the supplier who made the part/sub-component/component with the issue.

The platform must make it easy to define, maintain, alter, and otherwise work with the bill of materials. It shall be easy to instantiate an instance for each supplier of a product and trace all the way down to the mine or fields the raw materials come from, or the recovery/recycling plants if the materials are being re-used in a sustainable fashion.
Manufacturing Visibility The visibility doesn’t stop at the BoM. It begins at the BoM. For each product you buy from each supplier, you need to track the supplier’s production capacity at the plant, as well as how that capacity is influenced by other products, and switchover time. (If you buy multiple products that use the same production line, then you can’t get full capacity of both.) It must be easy to see all manufacturing information related to a plant of a supplier, how many products it is associated with, and what tradeoffs are in effect when you order a specific product from a supplier.

The platform must be capable of calculating the units per hour/day/week, the switchover time, and how many units of each could be produced given a requirement for one product. (And the same must hold true for three or more different products/configurations.)

It’s critical that the platform allow for easy definition and manipulation of BoM instantiations, supplier plant nodes, manufacturing details, production line capability, and associated timings.
Public vs. Private Differentiation The platform must be able to maintain the distinction between public and private entities, specific to the countries the entities are located/headquartered in, as well as the different types of information the organization needs to keep on both from a risk perspective. In some countries, public entities are more rigorously regulated and in other countries, private entities could be more heavily regulated. The platform needs to allow a buying organization to ensure that the entities are acting appropriate to their type. Also, investments and sanctions can sometimes work differently depending on entity type.

The platform must be capable of tracking entity type, associate the entity with the relevant regulations and requirements based on the type, and alert the organization if anything changes with respect to the type or any change that could impact the type classification.
Predictive Sub-Tier Mapping A supplier may not always disclose it’s sub-tiers. In such a situation, the platform must predict which sub-tier suppliers are being used based on product type, raw material, raw material availability, available transport networks, and so on.

The platform must contain an adaptive algorithm that learns as new information becomes available, continuously updates its knowledge from market data feeds (import/export logs are often public information), and integrates with third party (commodity) markets that can predict changes over time.

Source-to-Pay+ Part 6: (In) Transport Risk

In Part 1 we noted that Risk Management went much beyond Supplier Risk, and the primitive Supplier “Risk” Management application that is bundled in many S2P suites. Then, in Part 2, we noted that there are risks in every supply chain entity; with the people and materials used; and with the locales they operate in. In Part 3 we moved onto an overview of Corporate Risk, in Part 4 we took on Third Party Risk (in Part 4A and Part 4B), and then in Part 5 we laid the foundation for Supply Chain Risk (Generic).

As part of supply chain risk, we highlighted transport mapping and tracking as a key risk that the system should track, but noted that a generic supply chain risk management system would generally not be a full featured transport risk management system because such a system would also monitor and mitigate risks of goods in-transport. (Not just risks at nodes.) Such a system has a number of specific requirements beyond the basics outlined in our last article. In this article, we are going to discuss a number of those specific requirements.

Capability Description
Modal-Specific Support Cargo can travel by land, rail, sea, or air. As a result, an in-transport platform has to recognize each of these modes, the differences between them, the data that needs to be tracked, and the data that can be obtained from carriers providing each mode.

Such a platform should integrate with industry standard data feeds from TMS (Transport Management Systems), data feeds from major carriers, GPS systems, and other systems that provide data on your shipments, where they are, and when they are expected to get to the next location if the current leg of transport does not have a real-time GPS feed.
Cold Chain/Hazardous Not all cargo can travel dry at room temperature. Some has to travel wet, some has to travel refrigerated or frozen, and some has to travel with special precautions for hazardous materials. It’s critical that such a platform be able to tag items with these tags, these transport requirements, and assess the risks associated with the transport based on carrier, route, geolocation, etc.

Such a platform must be able to detect when a risk materializes or escalates, such as the delivery time estimate being pushed forward by a week when the cargo was only expected to have a shelf-life of six (6) days when delivered, extreme weather phenomena suddenly materializing in the region of the transport vehicle, or dangerous (man-made) accidents occurring as a result of a leak, accident, or failure in transport.
Manifests/Bills of Lading The system should be capable of accepting bills of lading and cargo / shipping manifests and ensuring that the bill of lading exactly matches the shipment that is expected from the supplier, the cargo/shipping manifest exactly matches the bill of lading, and the inventory at the dock/yard matches the cargo manifest. This is the only way to minimize the chance of theft and fraud during transport. And by fraud, we don’t just mean your goods disappearing, we mean your containers and your company being used to smuggle goods into one or more countries where the goods are prohibited in those countries.

The system should also be capable of identifying carriers who have had incidents in the past, the carriers who are most at risk due to the regions they operate in, and the carriers who are most at risk due to the products they are carrying, both for you and for others (based on public manifests).
Ports The system will track detailed information on the ports that are used in the supply network. It will maintain information on port capacities / throughput, the carriers that go in and out, the equipment, the security at the dockyards, and so on. It will maintain information on the labour situation (last strike, the date the contract ends, likelihood of a strike/slowdown, etc.) as well as the available workforce.

The system should be capable of tying in weather information, local geopolitical information, economic information, and other disruptions that could affect the port, as well as any other risk-based factors that are relevant.
Canals/Straits A lot of the world’s goods flow through canals (primarily the Panama and Suez) and straits to ports that are off of lakes and seas and not on the Atlantic or Pacific Ocean. While there are the risks of natural disasters just as there are on the high seas, there are also the geopolitical risks associated with all of the countries that border the canal or strait. (Especially if they are unfriendly to the country of origin, destination, or registration of the ship.)

The system must track all of the risks specific to the canals and ports that the organization, and its carriers, use in the ocean-based transport of goods.
Warehouses/Cross-Docks Most goods procured by an organization will live in multiple warehouses in their journey through the supply chain. The suppliers, the shipper’s local cross-dock, the port warehouse, the railroad cross-dock, your primary warehouse, and the regional warehouses that supply your local retail centers or manufacturing plants, as appropriate. These docks all pose a security risk.

The system should support all of the third party risk capabilities that are relevant for the owner/operator of the warehouse, the locale the work force is in, the third parties that provide the workers, and any other risks that can be identified and monitored for.
In-Yard (Rail/Dock) Sometimes the goods are in a warehouse, and sometimes they are just in a yard at the dock or the (rail)yard waiting to be loaded on a truck or a train to be taken to a cross-dock or warehouse. The risk will be a blend of warehouse/cross-dock and port/rail risks, tailored to the relevant locale.

The system should support all of the associated third party risk capabilities that are relevant, and, as with the warehouse/cross-dock, support risks that can be identified and monitored for.
Airports/ Some goods will go by sea, some by rail, some by land, and some by air. Airports have their own class of risks — which can include hijackings, crashes, and way too many carriers and personnel in and out of shared warehouses.

Similar monitoring to in-yard, but expanded to meet the specific need of airports servicing your cargo.
Driver/Conductor/Captain The biggest risks in transport are often not the third party carriers you deal with, but the people — are they appropriately vetted, trained, certified, and monitored? Who are they associated with? Can those associates pose risks? Do they need to be monitored? If so, when and how?

This system should integrate with an employee/contractor certification and monitoring systems to at least make sure all employees/contractors assigned to the organization’s cargo have appropriate licenses, certifications, training, and insurance.

And, of course, an In-Transport Risk Management system will also need a host of generic analytics/planning/monitoring capabilities, but since many of these are common, and since stand alone risk-focussed analytics applications are also part of the plethora of offerings out there, instead of discussing these generic features in this and every other article, as we noted in our coverage of Corporate Risk, we will instead discuss these capabilities in an article dedicated to Risk Analytics and Monitoring.

A Good Negotiation is Key in Technology Acquisition

But whatever you do, please don’t mistake cost savings with value generation. But, as usual, let’s backup.

A recent article over on The Financial Express on the importance of a technology procurement negotiator noted that the art of negotiation has taken on a whole new level of complexity, especially in technology procurement and that discovering the most equitable prices … is a strategic imperative at a time when maximizing returns on investments is paramount.

And this is certainly true, as are most of the other messages in their article. Specifically, such a negotiator must:

  • understand the digital disruption
  • have high intelligence, which must go beyond technical expertise
  • understand the high stakes of technology investments
  • have the personality, worldview, and knowledge to navigate the negotiation beyond the technical aspects
  • be able to reflect on the bigger picture
  • be able to sync with the project

… but the criticality of ensuring that the technology procured provides exceptional value for the money spent cannot be over-emphasized. One cannot understate the importance of understanding the product’s role, functionality, and how it aligns with organisational goals. It doesn’t matter how much you save if the product isn’t the right fit. It’s critically important to not only have the technology experts identify the products that could serve your needs, but the right configurations, the associated services that will be required, and the right partners for the organization.

Additional savings is worthless if it comes at the expense of the vendor removing a key module from the reduced offer, not including necessary implementation or integration services, limiting computing or storage, and so on. If you end up paying significantly more after implementation as a result of change-orders, you not only haven’t saved, but you’ve cost the organization more. This is what often gets missed when negotiators lead. While the eventual owners shouldn’t lead, as they’ll always go with their top ranked provider (even if three systems can do the job equally well, and it’s just a preference as to which system is easiest to use), if they’re not kept in lock stop, it’s easy to miss key details or requirements or stray away from what is truly needed for value generation and ROI in the search for the ultimate deal. This is especially true if the negotiator brings a new vendor in at the last minute for price pressure, believing the new vendor, if not perfect, meets all the key requirements, when in reality the vendor’s platform doesn’t.

This is especially important to remember in SaaS negotiations, where it’s common knowledge that most organizations that buy without using a skilled negotiator are overpaying by an average of 30% or more. This is because an average negotiator’s inclination is to drive for massive discounts to prevent overspend, which might result in not only choosing the less optimal vendor, but the less optimal agreement. At the end of the day, price matters, but ROI matters more, especially in Procurement where the right solution will generate a 5X ROI or more and the wrong solution will barely pay for itself.