How to calculate the ROI of an enterprise multi-cloud transformation

The steering pack lists five clouds and a percentage taken from a conference slide. Nobody has timed the quote. After go-live the quote still takes a first pass and a second pass, because the price is typed again from the price list into the opportunity. The cloud count has gone up. The hours have not moved. Finance asks for the percentage again, and the programme answers with the footprint. That answer is not a return. It is a list of what you pay for.

A return is a change against a baseline you wrote down before the programme. The baseline is the process you mean to change, counted in hours and in rework. How long to produce a quote. How long to raise an invoice. How long to close a case. How many hours go into the spreadsheet that corrects the CRM. The second call that exists because the first record was incomplete. The report someone rebuilds because they do not trust the first one. Write the date and the name of the person who counted. Without that page, a business case is a cloud list with a percentage taped to it, and the percentage will outlive every person who knows it was borrowed.

#Time one process, then stop talking about clouds

Do this for one process, not for the whole estate in a single number. Pick the process the programme claims it will change. If the claim is "faster quotes," the process is quoting. If the claim is "cases closed without a second call," the process is the case. If nobody can point at a process, the claim is not ready to be costed. "One view of the customer" is a hope until someone can show the old view, how long it took to assemble, and how often it was wrong. Multi-cloud programmes fail this test when the benefit is a diagram and the cost is real.

Sit with the people who do the work. Time ten real instances, not a workshop estimate. A workshop estimate remembers the good day and forgets the chase. Note the rework separately from the first pass. A quote that takes a first sitting, then another sitting because the price was wrong, is two sittings. Count both. Write what the second sitting was for: a missing discount approval, a product that was not on the price list, a customer name that did not match the billing account. Those reasons are the design. A total with no reasons is a number you cannot improve.

Write the date, the person who held the watch, and the ten identifiers, so someone else can open the same records. A baseline that cannot be reopened cannot be recounted. Store it where the steering papers live, not in a notebook that leaves with the project manager. If the ten instances are not representative, say how you chose them. Ten quotes from one friendly seller is a different baseline from ten quotes across the teams that actually struggle. Either can be honest. Pretending they are the same is how the recount later looks like a failure of the programme when it is a failure of the sample.

If you cannot name the process, stop the return slide. Do not substitute a count of objects, users, or clouds. Those describe the estate. They do not describe a change. The meeting that cannot name the process is the meeting that should not approve the spend, and saying so early is cheaper than discovering it in the recount.

#Costs you can name, and cells you leave blank

Salesforce describes Agentforce pricing in one sentence: "Our pricing options include Flex Credits, Resolutions, or per-user licensing, designed to fit how and where you deploy AI." That is a cost shape for one product. It is not a saving, and it is not a return. Put the option you will actually buy on the cost page, in the unit the contract uses. If you have not chosen, say so, and leave the cell blank. Do not convert an unchosen price into a benefit by assuming the cheapest option and the busiest month. The steering group will remember the benefit and forget that you had not bought it.

Data 360 help is equally plain: "Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs." Add-on licences are a cost. Usage that can be adjusted is a commercial conversation, not a free input. If you do not know the edition and the add-ons, you do not know the cost. Leave the cell blank. A round number invented to fill a blank will be the number the steering group remembers, and it will be repeated in the next pack as if it had been measured. Limits differ by edition and by what you bought. This page will not print a cap. Look up the figure for the contract you hold, on the date you write the page, and put that date next to the figure.

Implementation time belongs on the same page. Internal hours. Partner hours. The hours the business spends in workshops instead of in the process you just timed. Those hours are part of the cost of the change. A case that is shorter by two hours, and a workshop programme that consumed the team's quarter, is not a return until you have put both on the page. Training time counts when it replaces selling or dispatching. It does not count as a benefit because attendance was high.

#A footprint is not a return

Owning sales, service, a data platform, and a field product is a description of what you pay for. It becomes a return only when the timed process gets shorter or the timed rework stops. Adding a cloud because the diagram looked empty increases the footprint. It may also increase the cost page: another licence, another add-on, another set of workshops. None of that is a benefit until the ten instances, timed again, come back shorter or cleaner.

Recount the process after go-live, the same way, with a named person, on a date you set before you started. Same process. Same kind of instance. Rework separated from the first pass. If the hours got worse, that is the result. Publish it beside the baseline. A programme that only reports the cloud count has not calculated anything, and a programme that recounts only the instances that improved has calculated a wish. Put the worse ones on the page. They are how you decide whether to continue, change the design, or stop.

The expected change, before go-live, is written as fewer hours or less rework, not as a ratio. "The second sitting on the quote stops, because the price is taken from the price list instead of typed again." That sentence can be checked. "Efficiency improves" cannot. The person who will recount it is named now, so the job is not orphaned when the project team rolls off. If that person was also the person who counted the baseline, the method is more likely to match. If they are different people, have them time one instance together before the baseline is filed.

#What is cheap to correct, and what sticks

Cheap, before anyone has presented the percentage: throwing the borrowed figure away, naming the process, timing ten instances, listing the licences you can actually point at. The steering group may be impatient. The impatience is cheaper than a year of reporting a number nobody can recompute.

Expensive, once the percentage is in a board paper: every later conversation starts from it. People will explain variances against a figure that was never yours. Correcting it looks like the programme is slipping, when the programme is meeting a baseline you had not written. Write the baseline before the first pack. If a pack has already gone out with a borrowed figure, the next pack says so in a sentence and replaces it with the hours. Do not leave both numbers in circulation. The borrowed one will be the one that gets repeated, because it is round.

Three ways teams avoid the watch. They average the whole company into one "productivity" number, so no process can be found inside it. They time a demonstration in a conference room and call it the baseline. They treat a licence discount as a return on the transformation, which is a purchasing result, not a change in the work. A discount can sit on the cost page. It does not shorten the quote. The quote shortens when the second sitting stops, and you will know that only if you counted the sittings.

Two processes do not become one number. If the programme claims both a shorter quote and a shorter case, time them separately, with two baselines and two recounts. Averaging them lets a gain in one hide a loss in the other, and the pack will report the average as success. A survey that asks people whether they feel faster is not a substitute for the watch. Feeling faster while the second sitting is still in the field history means the field history is the baseline you should have used.

The recount meeting has an agenda that fits on the same page. Read the ten new instances against the ten old ones. Name which reasons for rework disappeared, and which new reasons appeared, because a new system often replaces one kind of rework with another. A price that is no longer retyped, and a credit check that now waits on an integration, is not automatically fewer hours. Count the wait. If you cannot explain a movement in hours by a movement in those reasons, you do not understand the result yet, and you should not translate it into a ratio.

Present one page. The process. The baseline in hours. The costs you can name. The change you expect, stated as fewer hours or less rework, with the person who will recount it. No percentage you did not calculate from those hours. If finance wants a ratio, they can divide your recounted hours by your named costs. Hand them the inputs. Do not hand them a figure from a slide you did not measure.

The same hours-and-rework test is how a later quarter should be scored, which is the discipline in a roadmap that records whether the pain moved. A roadmap that cannot point at this baseline will fill up with clouds. This page is the baseline it should be pointing at.