Monthly Archives: November 2023

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.

The Big X are Pushing Operate Services … But Can They Really Offer Them? And Are They Real?

And if they are real, can anyone?

Backing up, in the beginning, there was traditional Business Process Outsourcing (BPO), which became very common in the 1980s and 1990s as the result of constant claims by McKinsey and their ilk that the only way businesses could enhance their flexibility and agility and maximize their competitive advantage was to outsource processes they weren’t good at to the Big X Outsourcing offices. (In some cases they weren’t wrong. When the business had no competence in a function, grossly overpaying someone with reasonable competence, even if that someone was not the expert the Big X claimed, generated a good return for the business. The function was done efficiently and effectively, negating the loss the business used to suffer, and it allowed the business to focus on the functions they did well, which increased their profit even as they (often unnecessarily) forked out seven (7) and eight (8) figures to the Big X every year. (And we say unnecessarily because most of the time they could have outsourced to a smaller, niche consultancy at one third to one half of the cost and achieved the same result.)

Then, as Big X tried to steal business from their competitors and niche firms tried to break in, they upgraded to “Managed Services” which was supposed to be more than just performing the service for you cost efficiently (by supposedly reducing your costs by doing it better, and thus, cheaper) and adding value. The idea was that it didn’t just take over a point-based function, but instead provided a dedicated team that basically took over an entire department for you, just offsite, and worked exclusively on your projects. They learned your business, and improved the service offering over time to not only maximize efficiency, but maximize value. If they took over your IT department, they learned the systems you used, optimized those, learned to provide quick and effective problem resolution on the help desk, and, when you needed a new solution, helped you identify the one that would work best with the systems you had. If they took over your AP, they learned your suppliers, your payment rules, your PO formats, and implemented systems that allowed them to match POs to invoices for high-value invoices to reduce overspend. They also helped you build catalogs from suppliers that could meet your MRO / internal needs at the lowest possible cost. And so on. Over time, they not only met SLAs, but improved on all key metrics.

But now a few of the Big X are saying that Managed Services is not enough to maximize value and you need premium “Operate Services” (which come at a premium price, of course). So what’s the difference? Hard to tell. The best definition we can find is it’s a “holistic approach that is focused on delivering outcomes and spurring innovation in a model that leverages automation and data insight to generate substantial business value”. the doctor thought that was what managed services was supposed to do for you? Other definitions indicate that “operate services” differentiate by providing “on demand access to expert talent”. Isn’t that why you use a managed service, so they can identify when the team needs a new expert and add that expert? Other definitions also indicate that “operate services” are more “collaborative”. Are they saying that the managed services they provided to you in the past, where they often acted as an entire department, weren’t collaborative? WTF?

In other words, while they are presenting it as a more advanced premium service model, for which they want to charge you a premium, it really isn’t, or shouldn’t be, because if it is, they are admitting they have been ripping you off for decades!

In some consultancies, it is just a specialization of managed services for IT/IT Security, Analytics-Heavy Functions like Strategic Procurement or Network Analysis, or highly technical functions like supplier identification in direct manufacturing. And it costs more because those people, who are much rarer than experts in traditional business functions and processes, are more expensive, as are the tools that they need to secure your enterprise, analyze your global spend, analyze your supply network, or analyze potential suppliers for your electronic components. And we can see how that could be fair, as long as they aren’t using “operate services” to increase costs across the board where there is absolutely no justification for it.  (And only using it to differing a subclass of specialized services they offer, and admitting its nothing more than managed services, just applied to a new set of business functions.)

But if the consultancy is trying to pitch these “Operate Services” across the board with claims that these new services are better and more specialized for your business than any other kind of service, then they are admitting they are currently ripping you off in your managed services and you should just fire them (from a cannon preferably — and TikTok it — it’s all the rage, right?). Because there should be no difference with the exception that the subclass of operate services we defined in the last paragraph generally require more advanced systems and more resources with a high TQ, which usually cost more. But that’s it.

So don’t fall for this brand new business con if they try to pull it on you — simply compare what they are offering to any other firm that says they can fully meet your needs with a traditional managed services model and give the business to the firm that is the most honest among those that can meet your needs.  (Basically, as far as <i>the doctor</i> can tell, some of these Big X Consultancies are just upset that they haven’t come up with a pressing new need they can take advantage of, so they are just relabeling what they have in the hopes you’ll fall for it.)