Category Archives: Best Practices

Spendata: A True Enterprise Analytics Solution

As we indicated in our last article, while Spendata is the absolute best at spend analysis, it’s not just a spend analysis platform. It’s a general-purpose data analytics platform that can be used for much more than spend analysis.

The current end-state vision for business data analytics is a “data lake” database with a BI front end. The Big X consultancies (aided and abetted by your IT department, which is only too eager to implement another big system) will try to convince you of the data paradise you’ll have if you dump all of your business data into a data lake. Unfortunately, reality doesn’t support the vision, because organizational data is created only to the extent necessary, never verified, riddled with errors from day one, and left to decay over time as it’s never updated. The data lake is ultimately a data cesspool.

Pointing a BI tool at the (dirty) lake will spice up the data with bars, pies, waves, scatters, multi-coloured geometric shapes, and so on, but you won’t find much insight other than the realization that your data is, in fact, dirty. Worse, a published BI dashboard is like a spreadsheet you can’t modify. Try mapping new dimensions, creating new measures, adding new data, or performing even the simplest modification of an existing dimension or hierarchy, and you’ll understand why this author likes to point out that BI should actually stand for Bullsh!t Images, not Business Intelligence.

So how does a spend analysis platform like Spendata end up being a general-purpose data analytics tool? The answer is that the mechanisms and procedures associated with spend analysis and spend analysis databases, specifically data mapping and dimension derivation, can be taken to the next level — extended, generalized, and moved into real time. Once those key architectural steps are taken, the system can be further extended with view-based measures, shared cubes where custom modifications are retained across refreshes, and spreadsheet-like dependencies and recalculation at database scale.

The result is an analysis system that can be adapted not only to any of the common spend analysis problems, such as AP/PO analysis or commodity-specific cubes with item level price X quantity data, but also to savings tracking and sourcing and implementation plans. Extending the system to domains beyond spend analysis is simple: just load different data.
The bottom line is that to do real data analysis, no matter what the domain, you need:

  • the ability to extend the schema at any time
  • the ability to add new derived dimensions at any time
  • the ability to change mappings at any time
  • the ability to build derivations, data views, and mappings that are dependent on other derivations, mappings, views, inputs, linked datasets, and so on, with real-time “recalc”
  • the ability to create new views and reports relevant to the question you have … without dumping the data to Excel
  • … and preserve all of the above on cube data refreshes
  • … in your own copy of the cube so you don’t have to wait for anyone to agree
  • … and get an answer today, not on the next refresh next month when you’ve forgotten why you even had the question in the first place

You don’t get any of that from a spend analysis solution, or a BI solution, or a database pointing at a data lake. You only get that in a modern data analysis solution — which supports all of the above, and more, for any kind of data. A data analysis system works equally well across all types of numeric or set-valued data, including, but not limited to sales data, service data, warranty data, process data, and so on.

As Spendata is a real data analysis solution, it supports all of these analyses with a solution that’s easier and friendlier to use than the spreadsheet you use every day. Let’s walk through some examples so you can understand what a data analysis solution really can do.

SALES ANALYSIS

Spending data consists of numerical amounts that represent the price, tax, duty, shipping, etc. paid for items purchased. Sales data is numerical amounts that represent the price, tax, duty, shipping, etc. paid for items sold.

They are basically the inverse of each other. For every purchase, there is a sale. For every sale, there is a purchase. So, there’s absolutely no reason that you shouldn’t be able to apply the exact the same analysis (possibly in reverse) to sales data as you apply to spend data. That is, IF you have a proper data analysis tool. The latter part is the big IF because if you’re using a custom tool that needs to map all data to a schema with fixed semantics, it won’t understand the data and you’re SOL.

However, since Spendata is a general-purpose data analysis tool that builds and maintains its schema on the fly, it doesn’t care if the dataset is spend data or sales data; it’s still transactional data and it’s happy to analyze away. If you need the handholding of a workflow-oriented UI, that can also be configured out of the box using Spendata‘s new “app” capability.

Here are three types of sales analysis that Spendata supports better than CRM/Sales Forecasting systems, and that can’t be done at all with a data lake and a BI tool.

Sales Discount Variation Analysis Over Time By Salesperson … and Client Type

You run a sales team. Are your different salespeople giving the same mix of discounts by product type to the same types of customers by customer size and average sales size?

Sounds easy right? Can’t you simply plot the product/price ratio by month by salesperson in a bubble chart (where volume size correlates to bubble size) against the average trend line and calculate which salespeople are off the most (in the wrong direction)? Sure, but how do you handle client type? You could add a “color” dimension, but when the bubbles overlap and the bubbles blur, can you see it visually? Not likely. And how do you remember a low sales volume customer which is a strategic partner, so has a special deal? Theoretically you could add another column to the table “Salesperson, Product/Price Ratio, Client Type, Over/Under Average”, and that would work as long as you could pre-compute the average discount by Product/Price Ratio and Client Type.

And then you realize that unless you group by category, you have entirely different products in the same product/price ratio and your multi-stage analysis is worthless, so you have to go back and start again, only to find out that the bubble chart is only pseudo-useful (as you can’t really figure it out visually because what is that shade of pink (from the multiple red and white bubbles overlapping) — Fuchsia, Bright, or Barbie — and what does it mean) and you will have to focus on the fixed table to extract any value at all from the analysis.

But then you’ll realize that you still need to see monthly variations in the chart, meaning you want the ability to drag a slider or change the month and have the bubble chart update. Uh-oh, you forgot to individually compute all the amounts by month or select the slider graph! Back to square one, doing it all over again by month. Then you notice some customers have long-term, fixed prices on some products, which messes up the average discount on these products as the prices for these customers are not changing over time. You redo the work for the third (or is it the fourth? time), and then you realize that your definitions of client type “large, medium, and small” are slightly off as a client that should be in large is in medium and two that should be in small were made medium. Aaarrrggghhh!!!

But with Spendata, you simply create or modify dimensions to the cube to segment the data (customer type, product groups, etc.) You leverage a dynamic view-based measure by customer type to set the average prices per time period (used to calculate the discount). You then use filters to define the time range of interest, another view with filters to click through the months over time, a derived view to see the performance by quarter, another by year. If you change the definition of client type (which customers belong to which client type), which products for customers are fixed prices, which SKU’s that are the same type, time range of interest, etc. you simply map them and the entire analysis auto-updates.

This flexibility and power (with no wasted effort) gives you a very deep analysis capability NOT available in any other data analysis platform. For example, you can find out with a few clicks that your “best” salesperson in terms of giving the lowest average discount is actually costing you the most. Turns out, he’s not serving any large customers (who get good discounts) and has several fixed price contracts (which mess up the average discounts). So, the discounts he’s giving the small clients, while less than what large customers get, are significantly more than what other salespeople provide to other small customers. This is something you’d never know if you didn’t have the power of Spendata as your data consultant would give up on the variance analysis at the global level because the salesman’s overall ratio looked good.

Post-Merger White-Space Analysis

White space sales analysis is looking for spaces in the market where you should be selling but are not. For example, if you sell to restaurants, you could look at your sales by geography, normalized by the number of establishments by type or the sales of the restaurants by type in that geography. In a merger, you could measure your penetration at each customer for each of the original companies. You can find white space by looking at each customer (or customer segment) and measuring revenue per customer employee across the two companies. Where is one more effective than the other?

You might think this is no big deal because this was theoretically done during the due diligence and the opportunity for overlap was deemed to be there, as well as the opportunity for whitespace, and whatever was done was good enough. The reality couldn’t be further from the truth.

If the whitespace analysis was done with a standard analytics tool, it has all the following problems:

  • matching vendors were missed due to different name entries and missing ids
  • vendors were not familied by parent (within industry, geography, etc.)
  • the improperly merged vendors were only compared against a target file built by the consultants and misses vendors
  • i.e. it’s poor, but no worse than you’d do with a traditional analytics tool

But with Spendata, these problems would be at least minimized, if not eliminated because:

  • Spendata comes with auto-matching capability
  • … that can be used to enrich the suppliers with NAICS categorization (for example)
  • Spendata comes with auto-familying capability so parent-child relationships aren’t missed
  • Spendata can load all of the companies from a firmographic database with their NAICS codes in a separate cube …
  • … and then federation can be used to match the suppliers in use with the suppliers in the appropriate NAICS category for the white space analysis

It’s thus trivial to

  1. load up a cube with organization A’s sales by supplier (which can be the output from a view on a transaction database), and run it through a view that embeds a normalization routine so that all records that actually correspond to the same supplier (or parent-child where only the parent is relevant) are grouped into one line
  2. load up a cube with organization B’s sales by supplier and do the same … and now you know you have exact matches between supplier names
  3. load up the NAICS code database – which is a list of possible customers
  4. build a view that pulls in, for each supplier in the NAICS category of interest, Org A spend, Org B Spend, and Total Spend
  5. create a filter to only show zero spend suppliers — and there’s the whitespace … 100% complete. Now send your sales teams after these.
  6. Create a filter to show where your sales are less than expected (eg. from comparable other customers or Org A or Org B). This is additional whitespace where upselling or further customer penetration is appropriate.

Bill Rate Analysis

A smart company doesn’t just analyze their (total) spend by service provider, they analyze by service role and against the service role average when different divisions/locations are contracting for the same service that should be fulfilled by a professional with roughly the same skills and same experience level. Why? Because if you’re paying, on average, 150/hr for an intermediate DBA across 80% of locations and 250/hr across the remaining 20%, you’re paying as much as 66% too much at those remaining locations, with the exception being San Francisco or New York where your service provider has to pay their locals a cost-of-living top-up just so they can afford to live there.

By the same token, a smart service company is analyzing what they are getting by role, location, and customer and trying to identify the customers that are (the most) profitable and those that are the least (or unprofitable when you take contract size or support requirements into account), so they can focus on those customers that are profitable, and, hopefully, keep them happy with their better talent (and not just the newest turkey on the rafter).

However, just like sales discount variation analysis over time by client type, this is tough as it’s essentially a variation of that analysis, except you are looking at services instead of products, roles instead of client types, and customer instead of sales rep … and then, for your problem clients, looking at which service reps are responsible … so after you do the base analysis (using dynamic view based measures), you’re creating new views with new measures and filters to group by service rep and filter to those too far beyond a threshold. In any other tool, it would be nigh impossible for even an expert analyst. In Spendata, it’s a matter of minutes. Literally.

And this is just the tip of the iceberg in terms of what Spendata can do. In a future article, we’ll dive into a few more areas of analysis that require very specialized tools in different domains, but which can be done with ease in Spendata. Stay tuned!

DEAR ENTERPRISE PROCUREMENT SOFTWARE BUYER: THERE ARE NO FREE RFPs!

This shouldn’t have to be said (again), but apparently it does since Zip has relaunched the FREE RFP madness in Source-to-Pay (that began in 2006 when Procuri first aggressively launched the Sourcing, Supplier Management, Contract Management, and Spend Analysis RFPs) with an RFP that is intake heavy, orchestrate light, process deficient, and, like many RFPs before, completely misses some of the key points when going to market for a technology solution. (Especially since there isn’t a single FREE RFP template from a vendor that isn’t intrinsically weighted towards the vendor’s solution, as it’s always written from the viewpoint of what the vendor believes is important.)

the doctor has extensively written about RFPs and the RFP process here on SI in the past, but, at a high level, a good RFP specifies:

  • your current state,
    it does NOT leave this out leaving the vendor to guess your technical and process maturity
  • what you need the solution to do
    NOT just a list of feature/functions
  • what ecosystem you need the solution to work in
    NOT just a list of protocols or APIs that must be supported
  • where the data will live
    and, if in the solution, how you will access it (for free) for exports and off-(vendor-)site backups, do NOT leave this out
  • what support you need from the vendor
    NOT just whether the vendor offers integration / implementation services and their hourly / project rate
  • any specific services you would like from the vendor
    NOT a list of all services you might want to buy someday
  • what the precise scope of the RFP is if it is part of a larger project
    NOT a blanket request for the vendor to “address what they can”
  • what regulations and laws you are subject to that the vendor must support
    NOT just an extensive list of every standard and protocol you can think of
  • what languages and geographies and time zones you need supported
  • any additional requirements the vendor will need to adhere to based on the regulations you or the vendor would be subject to and additional requirements your organization puts in place
    NOT endless forms of every question you can think of that might never be relevant
  • your goal state,
    it does NOT leave the vendor to guess what you are looking for (note that “goal” defines what you want to achieve, it is up to the vendor to define how they will help you achieve it)
  • what (management) processes you use to work with vendors — and —
  • what collaboration tools you make available to vendors and what your expectations are of them

And it is only created after a current state assessment, goal state specification, and key use-case identification so that it is relatively clear on organization needs and vendors have no excuse to provide a poor response.

Furthermore, a good RFP does NOT contain:

  • requests for features/functions you don’t currently need (but you can ask for a roadmap)
  • specific requests for a certain type of AI/ML/Analytics/Optimization/etc. when you don’t even know what that tech actually does — let the vendor tell you, and then show you, how their tech solves their problem
    (after all, there are almost NO valid uses for Gen-AI in S2P)
  • specific requests on the technology stack, when it doesn’t matter if they use Java or Ruby, host on AWS or Azure, etc.
  • requests for audits (tech, environmental, social welfare, etc.) when you haven’t selected the vendor for an award, pending a successful negotiation
  • requests for service professional resumes when you haven’t selected the vendor for an award that includes professional service, pending a successful negotiation
  • requests for financials, when you haven’t selected the vendor for an award pending a successful negotiation
    (because these last three [3] will scare some vendors off and possibly prevent the best vendor for you from even acknowledging your RFP exists)

And, a good RFP, goes to the right providers! This means that you need to select providers with the right type of solution you need before you issue the RFP, and then only issue to providers that you know offer that type of solution. (You can use analyst reports here if you like to identify potential vendors, but remember these maps cannot be used for solution selection! You will then need to do some basic research to make sure the vendor appears to fit the criteria.)

And if there are a lot of potential providers, you may need to do a RFI — Request for Interest / Intent (to Bid) — where you specify at a high level what the RFP you intend to issue is for, and if you get a lot of positive responses, do an initial call with the providers to confirm not only interest but the solution offered is relevant to your organization. (After all, at the end of the day, as The Revelator is quick to point out, it’s as much about the people behind the technology as the technology itself if you expect to be served by the provider.)

And even if you don’t need to an RFI before the RFP, you should still reach out to the vendors you want to respond, let them know the RFP is coming, and let them know you’ve done your research, believe they are one of the top 5 vendors, and are looking forward to their response. (Otherwise, you might find you don’t get as many responses as you’d hope for as vendors prioritize RFPs that they believe they have a good shot at winning vs. random unexpected RFP requests from unknown companies.)

At the end of the day, if you don’t know:

  • what the main categories of S2P+ solutions are
  • what the typical capabilities of a solution type are, what’s below, average or above
  • who the vendors are
  • how to determine your current state of process maturity (and how that compares to the industry, market, and best-in-class) and what a solution could do for you
  • how to evaluate a vendor’s solution
  • how to evaluate a vendor overall
  • how to write a good RFP that balances core business, tech, and solution requirements to maximize your chances of finding a good vendor for you

and the reality is that you most likely don’t (as less than 10% of Procurement departments are world class, as per Hackett research going back to the 2000s where they also determined the typical journey for an organization to become best-in-class in Procurement was 8 years, and that’s the minimum requirement to write a world-class technology RFP), then you should engage help from an expert to help you craft that RFP, be it an independent consultant or firm that specializes in Procurement transformation.

It is also critically important that the firm you select to help you needs to be neutral (not aligned with one solution provider who refers implementations to them in return for potential customer referrals) and that the firm does not rely on analyst maps either!

If you want help, the doctor has relationships with leading, neutral, firms on both sides of the pond who can help you, and who he will work with to make sure the technology / solution component is precisely what you need to get the right responses from vendors. Simply contact the doctor (at) sourcinginnovation [dot] com if you would like help getting it right.

Simply put, getting help with your technology RFP is the best insurance money you can spend. When you considering that, all in, these solutions will cost seven (7) or eight (8) figures over just a few years, you should be willing to spend 5% to 10% of the initial contract value to make sure you get it right. (Especially when there isn’t a single Private Equity Firm that wouldn’t invest in a technology player without doing a six [6], if not seven [7] figure due diligence first … and sometimes the firm will do this and then walk away! At least in your case, when you work with someone who can identify multiple potential vendors, you’re certain to find one at the end of the day.)

Procurement 2024 or Procurement’s Greatest Hits? McKinsey’s on the money, but … Part 4

… in some cases this is money you should have been on a decade ago!

Let’s backtrack. As we noted in Part 1, McKinsey ended Q1 by publishing a piece on Procurement 2024: The next ten CPO actions to meet today’s toughest challenges which had some great advice, but in some cases these were actions that your Procurement organization should have been taking five, if not ten years ago. And, if your organization was doing so in these cases, should be moving on to true next actions the article didn’t even address.

So, as you probably guessed, we’re in the midst of discussing each one, giving credit where credit is due (they are pretty good at strategy after all), and indicating where they missed a bit and tell you what to do next if you are already doing the actions you should have been doing years ago. And, just like we did to THE PROPHET‘s predictions, grade them. In this third instalment, we’ll tackle the next three actions, which they group under the heading of:

OPERATING MODEL OF THE FUTURE

9. Digitize end-to-end procurement processes. A-

This is yet another action that you should have been working on since the first Procurement platform hit the market over 25 years ago, but an action that you likely couldn’t have completed until recently when the introduction of orchestration platforms made the interconnection of all systems used by Procurement affordable for the average company, even when the company needed connectivity with systems in Finance, Logistics, Risk, and Supply Chain to access necessary pieces of information for Procurement to adequately do its job. (Before these systems, you needed to be a large enterprise with a huge IT budget to afford the integration work to attempt this.) Plus, the “AI” tools you need to digitize paper documents used by old-school, classify data, process contracts to identify potential issues, etc. used to be too pricey — now that seemingly every vendor has them, they are affordable to.

10. Build new capabilities for the buyer of the future. A+

Prepare the organization for Procurement’s future by investing in new abilities for advanced market research, integrated technology, and talent development. Equip procurement professionals with deep insights and tools to understand and address supply market dynamics, risks, economics, and ESG. Given how supply chains have been in constant flux since the start of COVID, with no end in sight as a result of geo-political conflict, natural events (drought in the Panamanian canal) and disasters, supply shortages, rampant cost increases, and so on, the organization is going to need every capability available today, and a few not invented yet, to survive tomorrow. Start researching, testing, and developing now … before it’s too late. (Just leave Gen-AI out of the picture!)

So, putting it all together, the grades were B, B, A, B+, A-, A, B+, A+, A-, A+. Not a bad report card.

Procurement 2024 or Procurement’s Greatest Hits? McKinsey’s on the money, but … Part 3

… in some cases this is money you should have been on a decade ago!

Let’s backtrack. As we noted in Part 1, McKinsey ended Q1 by publishing a piece on Procurement 2024: The next ten CPO actions to meet today’s toughest challenges which had some great advice, but in some cases these were actions that your Procurement organization should have been taking five, if not ten years ago. And, if your organization was doing so in these cases, should be moving on to true next actions the article didn’t even address.

So, as you probably guessed, we’re in the midst of discussing each one, giving credit where credit is due (they are pretty good at strategy after all), and indicating where they missed a bit and tell you what to do next if you are already doing the actions you should have been doing years ago. And, just like we did to THE PROPHET‘s predictions, grade them. In this third installment, we’ll tackle the next three actions, which they group under the heading of:

INTEGRATED MARGIN MANAGEMENT

Coordinate Response for Integrated Margin Management. B+

This is something that should have been done since your Procurement department started strategic sourcing — without a good estimate of the supplier’s cost of goods sold (COGS), there’s no way to know if the bid, or negotiated price, is good or not, or how much margin you are getting taken for (especially if there is price collusion among all the suppliers you invited to the event to keep bids in a certain range, no matter what).

However, in order to truly understand the COGS, you need to monitor commodity and raw material costs in almost real-time; understand the labour, energy and water requirements in production and the local market costs where the supplier’s production facilities are; monitor the local transportation costs (and any surges due to fuel increases, truck or container shortages, re-routings due to route closures or geopolitical situations, etc.) and that’s a much taller order than you had to worry about last decade to maintain a good grip on your supplier’s current COGS. You’ll even have to work closely with engineering, supply chain and logistics to make sure you’re getting it right.

Redefine Portfolio and Product Design. A+

While the latter is something R&D/Engineering should be doing every few years, it’s now critically important that Procurement get involved and guide engineering with respect to which products are, or in danger of, becoming too expensive due to material scarcity, a limited supply base that can manufacture the products, and changing consumer perception and desires regarding what they want from a certain product. As the article says, it’s becoming critical to help R&D/Engineering look for ways to reduce these dependencies, expedite qualification, and increase resilience by pointing out key products to address, key concerns, potential alternatives that are now available to the organization, and so on.

Procurement also needs to aggressively work with Marketing and Sales to shift demand away from products that need to be sunset due to end of life, cost, supply, or sustainability considerations, as well as shift demand to products that are more profitable, sustainable, or secure from a supply availability perspective. It can no longer be about what Sales thinks it can sell, but what Sales needs to sell for the organization as a whole to be successful.

Bring Back the Interns!

Even the offshore interns!

And since, like Meat Loaf,

I know that I will never be politically correct
And I don’t give a damn about my lack of etiquette

I’m going to come out and say I long for the days when AI meant “Another Indian”. (In the 2000s, the politically incorrect joke when a vendor said they had AI, especially in spend classification, was that the AI stood for “Another Indian” in the backroom manually doing all of the classifications the “AI” didn’t do and redoing all the classifications the “AI” got wrong over the weekend when the vendor, who took your spend database on Friday, promised to have it by Monday).

The solution providers of that time may have been selling you a healthy dose of silicon snake oil, but at least the spend cube they provided was mostly right and reasonably consistent (compared to one produced with Gen-AI). (The interns may not have known the first thing about your business and classified brake shoes under apparel, but they did it consistently, and it was a relatively easy fix to remap everything on the next nightly refresh.)

At the end of the day the doctor would rather one competent real intern than an army of bots where you don’t know which will produce a right answer, which will produce a wrong answer, and which will produce an answer so dangerous that, if executed and acted on, could financially bankrupt or effectively destroy the company with the brand damage it would cause.

After all, nothing could stop me from giving that competent, intelligent, intern tested playbooks, similar case studies, and real software tools that use proper methodologies and time-tested algorithms guaranteed to give a good answer (even if not necessarily the absolute best answer) and access to internal experts who can help if the intern gets stuck. Maybe I only get a 60% or 70% solution at best, but that’s significantly better than a 20% solution and infinitely better than a 0% solution, and unmeasurably better than a solution that bankrupts the business. Especially if I limit the tasks the intern is given to those that don’t have more than a moderate impact on the business (and then I use that intern to free up the more senior resources for the tasks that deserve their attention).

As for all the claims that the “insane development pace” of (Gen)-AI will soon give us an army of bots where each bot is better than an intern, given that the most recent instantiation of Gen-AI released to the market, where 200 MILLION was spent on its development and training, is telling us to eat one ROCK a day (digest that! I sure can’t!), I’d say the wall has been hit, been hit hard, and until we have a real advancement in understanding intelligence and in modelling intelligence, you can forget any further GENeric improvements. (Improvements in specific applications, especially based on more traditional machine learning, sure, but this GEN-AI cr@p, nope.)

When it comes to AI, it’s not just a matter of more compute power. That was clear to those of us who really understood AI a couple of decades ago. AI isn’t new. Researchers were discussing it in the (19)50’s, ’56 saw the creation of Logic Theorist, which was arguably the birth of Automated Reasoning, ’59 saw the founding of the MIT AI lab by McCarthy and Minsky, and ’63, in addition to seeing the publication of “Computers and Thoughts“, saw the announcement of “A Pattern Recognition Program That Generates, Evaluates, and Adjusts Its Own Operators“, which was arguably the first AI program (as AI needs to adjust its parameters to “learn”).

That was over SIXTY (60) years ago, and we still haven’t made any significant advances towards “AI”.

Remember that we were told in the ’70s that AI would reshape computing. Then we were told in the 80s that the new fifth generation computer systems they were building would give us massively parallel computing, advances in logic, and lay the foundation for true AI systems. It never happened. Then, when the cloud materialized in the 00’s, we saw a resurgence in distributed neural nets and were told AI would save the day. Guess what? It didn’t. Now we’re being told the same bullshit all over again, but the reality is that we’re no closer now then we were in the 60s. First of all, while computing is 10,000 times more powerful than it was six decades ago (as these large models have 10,000 cores), at the end of the day, a pond snail has more active neurons (than these models have cores), and neuronal connections, in its brain. Secondly, we still don’t really understand how the brain works, so these models still don’t have any intelligence (and the pond snail is infinitely more intelligent). (So even when we reach the point when these systems are one million times bigger than they are today, which could happen this century, we still won’t have intelligence.)

So bring back the interns, especially the ones in India. With five times the population of the US, statistically speaking, India has five times the number of smart people, and your chances of success are looking pretty good compared to using an application that tells you to eat rocks.