Category Archives: FPA

Putting the A Back in FP&A with Automated, Integrated Planning

I was reading this blog post on Continuous Planning by Rob Kugel of Ventana Research the other day and it reminded me of one of my (and Rob’s) favorite sayings:

We need to put the A back in FP&A

This means that the financial planning and analysis (FP&A) team at many companies is so busy doing other things that it doesn’t have time to focus on what it does best and where it can add the most value:  analysis.

This begs the question:  where did the A go?  What are the other things that are taking up so much time?  The answer:  data prep and spreadsheet jockeying.  These functions suck time away and the soul from the FP&A function.

dataprep

Data-related tasks — such as finding, integrating, and preparing data — take up more than 2/3rds of FP&A’s time.  Put differently, FP&A spends twice as much time getting ready to analyze data than it does analyzing it.  It might even be worse, depending on whether periodic and ad hoc reporting is included in data-related task or further carved out of the 28% of time remaining for analytics, as I suspect it is.

spreadsheetsrule

It’s not just finance who loves spreadsheets.  The business does do:  salesops, marketingops, supply chain planners, professional services ops, and customer support all love spreadsheets, too.  When I worked at Salesforce, we had one of the most sophisticated sales strategy and planning teams I’ve ever seen.  Their tool of choice?  Excel.

This comes back to haunt finance in three ways:

  • Warring models, for example, when the salesops new bookings model doesn’t foot to the finance one because they make different ramping and turnover assumptions.  These waste time with potential endless fights.
  • Non-integrated models.  Say sales and finance finally agree on a bookings target and to hire 5 more salespeople to support it.  Now we need to call marketing to update their leadgen model to ensure there’s enough budget to support them, customer service to ensure we’re staffed to handle the incremental customers they sign, professional services to ensure we’re have adequate consulting resources, and on and on.  Forget any of these steps and you’ll start the year out of balance, with unattainable targets somewhere.
  • Excel inundation.   FP&A develops battle fatigue dealing with and integrating some many different versions of so many spreadsheets, often late and night and under deadline pressure.  Mistakes gets made.

So how can prevent FP&A from being run over by these forces?  The answer is to automate, automate, and integrate.

  • Automate data integration and preparation.  Let’s free up time by use software that lets you “set and forget” data refreshes.  You should be able to setup a connector to a data source one, and then have it automatically run at periodic intervals going forward.  No more mailing spreadsheets around.
  • Automate periodic FP&A tasks.  Use software where you can invest in building the perfect monthly board pack, monthly management reports, quarterly ops review decks, and quarterly board reports once, and then automatically refresh it every period through these templates.  This not only free up time and reduces drudgery; it eliminates plenty of mistakes as well.
  • Integrate planning across the organization.  Move to a cloud-based enterprise performance platform (like Host Analytics) that not only accomplishes the prior two goals, but also offers a modeling platform that can be used across the organization to put finance, salesops, marketingops, professional services, supply chain, HR, and everyone else across the organization on a common footing.

Since the obligatory groundwork in FP&A is always heavy, you’re not going to succeed in putting the A back in FP&A simply by working harder and later.  The only way to put the A back in FP&A is to create time.  And you can do that with two doses of automation and one of integration.

The Strategy Compiler: How To Avoid the “Great” Strategy You Couldn’t Execute

Few phrases bother me more than this one:

“I know it didn’t work, but it was a great strategy.  We just didn’t have the resources to execute it.”

Huh.  Wait minute.  If you didn’t have the resources to execute it, then it wasn’t a great strategy.  Maybe it was a great strategy for some other company that could have applied the appropriate resources.  But it wasn’t a great strategy for you.  Ergo, it wasn’t a great strategy.  QED.

I learned my favorite definition of strategy at a Stanford executive program I attended a few years back.  Per Professor Robert Burgelman, author of Strategy is Destiny, strategy is simply “the plan to win.”  Which begets an important conversation about the definition of winning.  In my experience, defining winning is more important than making the plan, because if everyone is focused on taking different hills, any resultant strategy will be a mishmash of plans to support different objectives.

But, regardless of your company’s definition of winning, I can say that any strategy you can’t execute definitionally won’t succeed and is ergo a bad strategy.

It sounds obvious, but nevertheless a lot of companies fall into this trap.  Why?

  • A lack of focus.
  • A failure to “compile” strategy before executing it.

Focus:  Think Small to Grow Big

Big companies that compete in lots of broad markets almost invariably didn’t start out that way.

BusinessObjects started out focused on the Oracle financials installed base.  Facebook started out on Harvard students, then Ivy league students.  Amazon, it’s almost hard to remember at this point, started out in books.  Salesforce started out in SMB salesforce automation.  ServiceNow on IT ticket management.  This list goes on and on.

Despite the evidence and despite the fame Geoffrey Moore earned with Crossing the Chasm, focus just doesn’t come naturally to people.  The “if I could get 1% share of a $10B market, I’d be a $100M company” thought pattern is just far too common. (And investors often accidentally reinforce this.)

The fact is you will be more dominant, harder to dislodge, and probably more profitable if, as a $100M company, you control 30% of a $300M target as opposed to 1% of a $10B target.

So the first reason startups make strategies they can’t execute is because they forget to focus.  They aim too broadly. They sign up for too much.  The forget that strategy should be sequence of actions over time.  Let’s start with Harvard. Then go Ivy League.  Then go Universities in general.  Then go everyone.

Former big company executives often compound the problem.  They’re not used to working with scarce resources and are more accustomed to making “laundry list” strategies that check all the boxes than making focused strategies that achieve victory step by step.

A Failure to Compile Strategy Before Execution

The second reason companies make strategies they can’t execute is that they forget a critical step in the planning process that I call the strategy compiler.  Here’s what I think a good strategic planning process looks like.

  • Strategy offsite. The executive team spends a week offsite focused on situation assessment and strategy.  The output of this meeting should be (1) a list of strategic goals for the company for the following year and (2) a high-level financial model that concretizes what the team is trying to accomplish over the next three years.  (With an eye, at a startup, towards cash.)

 

  • First round budgeting. Finance issues top-down financial targets.  Executives who own the various objectives make strategic plans for how to attain them.  The output of this phase is (1) first-draft consolidated financials, (2) a set of written strategies along with proposed organizational structures and budgets for attaining each of the company’s ten strategic objectives.

 

  • Strategy compilation, resources. The team meets for a day to review the consolidated plans and financials. Invariably there are too many objectives, too much operating expense, and too many new hires. The right answer here is to start cutting strategic goals.  The wrong answer is to keep the original set of goals and slash the budget 20% across the board.  It’s better to do 100% of 8 strategic initiatives than do 80% of 10.

 

  • Strategy compilation, skills. The more subtle assessment that must happen is a sanity check on skills and talent.  Do your organization have the competencies and do your people have the skills to execute the strategic plans?  If a new engineering project requires the skills of 5 founder-level, Stanford computer science PHDs who each would want 5% of a company, you are simply not going to be able to hire that kind of talent as regular employees. (This is one reason companies do “acquihires”).  The output of this phase is a presumably-reduced set of strategic goals.

 

  • Second round budgeting. Executives to build new or revised plans to support the now-reduced set of strategic goals.

 

  • Strategy compilation. You run the strategy compiler again on the revised plan — and iterate until the strategic goals match the resources and the skills of the proposed organization.

 

  • Board socialization. As you start converging via the strategy compiler you need to start working with the board to socialize and eventually sell the proposed operating plan.  (This process could easily be the subject of another post.)

 

If you view strategy as the plan to win, then successful strategies include only those strategies that your organization can realistically execute from both a resources and skills perspective.  Instead of doing a single-pass process that moves from strategic objectives to budgets, use an iterative approach with a strategy compiler to ensure your strategic code compiles before you try to execute it.

If you do this, you’ll increase your odds of success and decrease the odds ending up in the crowded section of the corporate graveyard where the epitaphs all read:

Here Lies a Company that Had a “Great” Strategy  It Had No Chance of Executing

Host Analytics World 2016 EPM Keynote Address

We’re just finishing up a fantastic Host Analytics World 2016, with over 800 people gathered together in San Francisco to talk about enterprise performance management (EPM).   Here are a few pictures to give you a feel for the event.

Here’s 49ers football legend Steve Young delivering his keynote address:

IMG_3627

Here’s me delivering my keynote on EPM in fair weather and foul.

IMG_3614

Here’s an artsy shot of someone taking a picture during my keynote.

IMG_3615

And, of course, here are our mascots, Tick and Tie, stuffing bags for Project Night Night, the philanthropic activity we had at the conference cosponsored by Host Analytics and our amazing customer, Thrivent Financial.

tick and tie

The conference has been superb and I want to thank everyone — customers, prospective customers, analysts, journalists, pundits, and partners — for being a part of this great event.

I find it amazing that at such a great time to be in the cloud EPM market that we have competitors more focused on business intelligence (BI), predictive analytics, and functional performance management than on core EPM itself.  At Host Analytics, we know who we want to be:  the best vendor in cloud EPM, serving the fat middle 80% of the market.  More importantly, perhaps, we know who we don’t want to be:  we don’t want to be a visual analytics vendor, a social collaboration vendor, or a sales performance management vendor — hence our partnerships with Qlik, Socialcast, and Xactly.

We serve finance, we speak finance, and we’re proud of that.  Oh, and yes, our customers, finance leaders, care about the whole enterprise so we offer not only solutions to automate core finance processes but also tools to model the entire enterprise and align finance and operations.

You can hear about this and other topics by watching the 75 minute keynote speech and demo, embedded below.

 

Finally, please remember to save the date for Host Analytics World 2017 — May 16 through 19, 2017.

nashville

 

CAC Payback Period:  The Most Misunderstood SaaS Metric

The single most misunderstood software-as-a-service (SaaS) metric I’ve encountered is the CAC Payback Period (CPP), a compound metric that is generally defined as the months of contribution margin to pay back the cost of acquiring a customer.   Bessemer defines the CPP as:

bess cac

I quibble with some of the Bessemerisms in the definition.  For example, (1) most enterprise SaaS companies should use annual recurring revenue (ARR), not monthly recurring revenue (MRR), because most enterprise companies are doing annual, not monthly, contracts, (2) the “committed” MRR concept is an overreach because it includes “anticipated” churn which is basically impossible to measure and often unknown, and (3) I don’t know why they use the prior period for both S&M costs and new ARR – almost everybody else uses prior-period S&M divided by current-period ARR in customer acquisition cost (CAC) calculations on the theory that last quarter’s S&M generated this quarter’s new ARR.

Switching to ARR nomenclature, and with a quick sleight of mathematical hand for simplification, I define the CAC Payback Period (CPP) as follows:

kell cac

Let’s run some numbers.

  • If your company has a CAC ratio of 1.5 and subscription gross margins of 75%, then your CPP = 24 months.
  • If your company has a CAC ratio of 1.2 and subscription gross margins of 80%, then your CPP = 18 months.
  • If you company has a CAC ratio of 0.8 and subscription gross margins of 80%, then your CPP = 12 months.

All seems pretty simple, right?  Not so fast.  There are two things that constantly confound people when looking at CAC Payback Period (CPP).

  • They forget payback metrics are risk metrics, not return metrics
  • They fail to correctly interpret the impact of annual or multi-year contracts

Payback Metrics are for Risk, Not Return

Quick, basic MBA question:  you have two projects, both require an investment of 100 units, and you have only 100 units to invest.  Which do you pick?

  • Project A: which has a payback period of 12 months
  • Project B: which has a payback period of 6 months

Quick, which do you pick?  Well, project B.  Duh.  But wait — now I tell you this:

  • Project A has a net present value (NPV) of 500 units
  • Project B has an NPV of 110 units

Well, don’t you feel silly for picking project B?

Payback is all about how long your money is committed (so it can’t be used for other projects) and at risk (meaning you might not get it back).  Payback doesn’t tell you anything about return.  In capital budgeting, NPV tells you about return.  In a SaaS business, customer lifetime value (LTV) tells you about return.

There are situations where it makes a lot of sense to look at CPP.  For example, if you’re running a monthly SaaS service with a high churn rate then you need to look closely how long you’re putting your money at risk because there is a very real chance you won’t recoup your CAC investment, let alone get any return on it.  Consider a monthly SaaS company with a $3500 customer acquisition cost, subscription gross margin of 70%, a monthly fee of $150, and 3% monthly churn.  I’ll calculate the ratios and examine the CAC recovery of a 100 customer cohort.

saas fail

While the CPP formula outputs a long 33.3 month CAC Payback Period, reality is far, far worse.  One problem with the CPP formula is that it does not factor in churn and how exposed a cohort is to it — the more chances customers have to not renew during the payback period, the more you need to consider the possibility of non-renewal in your math [1].  In this example, when you properly account for churn, you still have $6 worth of CAC to recover after 30 years!  You literally never get back your CAC.

Soapbox:  this is another case where using a model is infinitely preferable to back-of-the-envelope (BOTE) analysis using SaaS metrics.  If you want to understand the financials of a SaaS company, then build a driver-based model and vary the drivers.  In this case and many others, BOTE analysis fails due to subtle complexity, whereas a well-built model will always produce correct answers, even if they are counter-intuitive.

Such cases aside, the real problem with being too focused on CAC Payback Period is that CPP is a risk metric that tells you nothing about returns.  Companies are in business to get returns, not simply to minimize risk, so to properly analyze a SaaS business we need to look at both.

The Impact of Annual and Multi-Year Prepaid Contracts on CAC Payback Period

The CPP formula outputs a payback period in months, but most enterprise SaaS businesses today run on an annual rhythm.  Despite pricing that is sometimes still stated per-user, per-month, SaaS companies realized years ago that enterprise customers preferred annual contracts and actually disliked monthly invoicing.  Just as MRR is a bit of a relic from the old SaaS days, so is a CAC Payback Period stated in months.

In a one-hundred-percent annual prepaid contract world, the CPP formula should output in multiples of 12, rounding up for all values greater than 12.  For example, if a company’s CAC Payback Period is notionally 13 months, in reality it is 24 months because the leftover 1/13 of the cost isn’t collected until the a customer’s second payment at month 24.  (And that’s only if the customer chooses to renew — see above discussion of churn.)

In an annual prepaid world, if your CAC Payback Period is less than or equal to 12 months, then it should be rounded down to one day because you are invoicing the entire year up-front and at-once.  Even if the formula says the CPP is notionally 12.0 months, in an annual prepaid world your CAC investment money is at risk for just one day.

So, wait a minute.  What is the actual CAC Payback Period in this case?  12.0 months or 1 day?  It’s 1 day.

Anyone who argues 12.0 months is forgetting the point of the metric.  Payback periods are risk metrics and measured by the amount of time it takes to get your investment back [2].  If you want to look at S&M efficiency, look at the CAC ratio.  If you want to know about the efficiency of running the SaaS service, look at subscription gross margins.  If you want to talk about lifetime value, then look at LTV/CAC.  CAC Payback Period is a risk metric that measures how long your CAC investment is “on the table” before getting paid back.  In this instance the 12 months generated by the standard formula is incorrect because the formula misses the prepayment and the correct answer is 1 day.

A lot of very smart people get stuck here.  They say, “yes, sure, it’s 1 day – but really, it’s not.  It’s 12 months.”  No.  It’s 1 day.

If you want to look at something other than payback, then pick another metric.  But the CPP is 1 day.  You asked how long it takes for the company to recoup the money it spends to acquire a customer.  For CPPs less than or equal to 12 in a one-hundred percent annual prepaid world, the answer is one day.

It gets harder.  Imagine a company that sells in a sticky category (e.g., where typical lifetimes may be 10 years) and thus is a high-consideration purchase where prospective customers do deep evaluations before making a decision (e.g., ERP).  As a result of all that homework, customers are happy to sign long contracts and thus the company does only 3-year prepaid contracts.  Now, let’s look at CAC Payback Period.  Adapting our rules above, any output from the formula greater than 36 months should be rounded up in multiples of 36 months and, similarly, any output less than or equal to 36 months should be rounded down to 1 day.

Here we go again.  Say the CAC Payback Period formula outputs 33 months.  Is the real CPP 33 months or 1 day?  Same argument.  It’s 1 day.  But the formula outputs 33 months.  Yes, but the CAC recovery time is 1 day.  If you want to look at something else, then pick another metric.

It gets even harder.  Now imagine a company that does half 1-year deals and half 3-year deals (on an ARR-weighted basis).  Let’s assume it has a CAC ratio of 1.5, 75% subscription gross margins, and thus a notional CAC Payback Period of 24 months.  Let’s see what really happens using a model:

50-50

Using this model, you can see that the actual CAC Payback Period is 1 day. Why?  We need to recoup $1.5M in CAC.  On day 1 we invoice $2.0M, resulting in $1.5M in contribution margin, and thus leaving $0 in CAC that needs to be recovered.

While I have not yet devised general rounding rules for this situation, the model again demonstrates the key point – that the mix of 1-year and 3-year payment structure confounds the CPP formula resulting in a notional CPP of 24 months, when in reality it is again 1 day.  If you want to make rounding rules beware the temptation to treat the average contract duration (ACD) as a rounding multiple because it’s incorrect — while the ACD is 2 years in the above example, not a single customer is paying you at two-year intervals:  half are paying you every year while half are paying you every three.  That complexity, combined with the reality that the mix is pretty unlikely to be 50/50, suggests it’s just easier to use a model than devise a generalized rounding formula.

But pulling back up, let’s make sure we drive the key point home.  The CAC Payback Period is the single most often misunderstood SaaS metric because people forget that payback metrics are about risk, not return, and because the basic formulas – like those for many SaaS metrics – assume a monthly model that simply does not apply in today’s enterprise SaaS world, and fail to handle common cases like annual or multi-year prepaid contracts.

# # #

Notes

[1] This is a huge omission for a metric that was defined in terms of MRR and which thus assumes a monthly business model.  As the example shows, the formula (which fails to account for churn) outputs a CAC payback of 33 months, but in reality it’s never.  Quite a difference!

[2] If I wanted to be even more rigorous, I would argue that you should not include subscription gross margin in the calculation of CAC Payback Period.  If your CAC ratio is 1.0 and you do annual prepaid contracts, then you immediately recoup 100% of your CAC investment on day 1.  Yes, a new customer comes with a future liability attached (you need to bear the costs of running the service for them for one year), but if you’re looking at a payback metric that shouldn’t matter.  You got your money back.  Yes, going forward, you need to spend about 30% (a typical subscription COGS figure) of that money over the next year to pay for operating the service, but you got your money back in one day.  Payback is 1 day, not 1/0.7 = 17 months as the formula calculates.

SAP Cloud for Analytics: Tilting at Windmills

Back in the early 2000s when I was running marketing at Business Objects, Gartner’s then-lead BI analyst, Howard Dresner (known as the father of BI and the person who named the category) started pushing a notion called enterprise performance management (EPM).  Back then, EPM meant the unification of BI and planning/budgeting.

The argument in favor of EPM made sense and was actually kind of cool:  with BI you could ask any question, but BI never knew the correct answer.  What did that mean?

It meant that BI tools were primarily tied to operational systems and could tell you the value of sales/salesrep for any quarter in any region.  The problem was that BI didn’t know what the answer was supposed to be.  BI knew the cost of everything and the value of nothing.

The solution was tie to BI to financial systems, which were full of targets and thus could allow us not just to know the value of any given metric, but what the value of that metric should be.

It sounded great and I bought in.  More importantly, so did the category:

Then what happened?  In my opinion, pretty much nothing.  Sure Hyperion reps could increase deal sizes by trying to drop Brio licenses across the whole financial department, as opposed to just FP&A.  Cognos could cross-sell Adaytum, with the help of an overlay sales force.

But did integration happen?  No.  BI and financial planning/budgeting  consolidated, but they never converged.  This is interesting because it’s rare.  For example, by contrast, CRM really happened.  SFA vendors didn’t just acquire customer service vendors and marketing vendors — the three applications came together to create one category.

That didn’t happen with EPM.  You could always ask someone who worked at Hyperion my favorite question, “which side did you work on?” and you always heard either, “oh, the BI side,” or “oh, the finance side.”  You never, ever got asked to clarify the question.

Over time, EPM came to mean financial planning, budgeting, and consolidation (along with associated reporting/analytics) — and not the unification of BI and financial planning.

What did this prove?   You can put the two categories under one roof via consolidation, but the actual markets are oil-and-water and don’t mix together well.  Why?  Two reasons:

  • BI is a platform sale, EPM is an applications sale
  • BI is sold to IT, EPM is sold to the finance department

So other than selling to a completely different buyer with a completely different value proposition, they make excellent candidates for integration!  Put concretely, if you can’t talk about inter-company eliminations, AVB reports, AOPs, topside journal entries, long-range models, FX rate handling, and legal entities, then you can’t even start to sell EPM.  I marketed BI for 9 years and we talked a totally different language:  aggregate awareness, multi-pass SQL, slow-changing dimensions, and star schemas.  The two languages are not totally unrelated.  They are nevertheless different.

Despite this history, many vendors still seem hell bent on mixing EPM water with BI oil.  One cloud EPM vendor positioned themselves for years as a leader in “BI and CPM” somehow thinking the rock-bottom acquisition of a cheap scorecarding tool made them a player in the $15B BI market.

To be clear, I view EPM and BI as cousins.  Yes, in EPM we make scorecards, dashboards, and reports.  Yes, in EPM we do multi-dimensional modeling and analysis.  No doubt.  But we do it for finance departments, we tie our planning/budgeting systems to the general ledger and we are focused on both financial outcomes and financial reports.  Yes, we also care about integrating models across the organization — sales, marketing, services, and operations.  But we are not trying to sell generic infrastructure for making reports and visualizations across the enterprise.

Put simply, in EPM we use BI technologies to build financial applications that tie together the enterprise on behalf of the finance department.

Surprisingly, SAP didn’t get the consolidation-not-convergence memo.  This is somewhat amazing given that SAP is a strong player in both BI and EPM, but somehow hasn’t seemed to notice not only that the two markets never converged but also that there is a very good reason for that.  They are still tilting at windmills fighting to integrate two categories not destined for integration with a vintage-2002 message.

Here’s the press release:

SAP Redefines Analytics in the Cloud

WALLDORF — SAP SE (NYSE: SAP) today unveils the SAP Cloud for Analytics solution, a planned software as a service (SaaS) offering that aims to bring all analytics capabilities into one solution for an unparalleled user experience (UX).

Built natively on SAP HANA Cloud Platform, this high-performing, real-time solution plans to be embedded with existing SAP solutions and intends to connect to cloud and on-premise data to deliver planning, predictive and business intelligence (BI) capabilities in one analytics experience. The intent is for organizations to use this one solution to enable their employees to track performance, analyze trends, predict and collaborate to make informed decisions and improve business outcomes.

Note, that in addition to my strategic concerns, I have a few tactical ones as well:

  • This is a futures announcement without a date.  The service “planned.”  The “planned benefits” are stated.  The only thing I can’t find in the plan is an availability date.
  • Pricing hasn’t been announced either.  So other than knowing what it costs and when it will be available, it was an informative announcement.
  • While SAP is claiming that it’s previously announced SAP Cloud for Planning is included in the new offering, I have heard rumors on the street that SAP Cloud for Planning is actually being discontinued and customers will be moved to the new offering.  At this point, I’m not sure which is the case.

In the end, I’m not trying to beat on SAP in general.  I don’t love the Hana branding strategy, that’s true, but Hana itself (i.e., columnar, in-memory database) is a good idea.  I have no problems with SAP BI’s products — heck, my fingerprints still remain lightly on a few of them.  In EPM, we compete with SAP, so my agenda there is obvious.

But the thing I object to, the tilting at windmills, is that they are still banging the unify EPM and BI drum.  SAP’s new analytics may eventually end up a reasonable or good BI solution.  But if they’re betting serious chips on unifying BI and EPM it’s misguided.

Finance Transformation Themes from the IE FP&A Conference in Boston

After attending our amazing, sold-out Future of Finance Tour session in Minneapolis earlier this week, I swung out to Boston attend a chunk of the IE Groups’s FP&A Summit.

I had some great conversations with delegates and attended several interesting sessions.  Transforming finance was, as expected, a big theme.  Here are some of things I heard:

  • Old-school finance used to say, like a TV anchorperson, “we don’t make the news, we just tell you about it.”  This finance-as-spectator role is passé.
  • We need to transform FP&A from the engine room for report production — “here are the variances, don’t ask us about them” — to an active role in working with the business.
  • FP&A needs to no longer be the data crunchers, but insight providers who can tell the story in the data.
  • Finance needs to engage with the business.  Interact with them.  Sit with them.  Ask them.  Iterate with them.  Financial processes (e.g., forecasting) are inherently iterative and require finance to interact with subject matter experts (SMEs).
  • FP&A needs to challenge the conventional wisdom or common knowledge about the business.  It’s amazing how often common rules of thumb (e.g., which products are profitable and which aren’t) simply aren’t true when you dive into the data.
  • Finance should be more focused on having a seat at the table than knowing what the table cost and how far it is into its depreciation cycle.
  • “I spent years leveraging my ‘CPA’ doing copy / paste / attach from Excel spreadsheets into board books and presentations.”
  • While overuse of Microsoft Excel is definitely part of the problem, Excel is also definitely part of the solution.   “There are over 1,000 person-years of Excel experience in this (not very big) room.  You can’t throw that out.”
  • “I fell out of bed knowing how to do that in Excel.”
  • In leveraging technology for FP&A the cloud is now a given — five years ago that was not the case.

And the old classic, which I really believe in:  finance needs to focus on becoming a business partner to the CEO and the business.

It was a great conference and I’m glad I stopped by.

The Confusion Around Workday Planning

Workday’s planning strategy is enough to make an observer confused.

This far in, it looks pretty clear what happened:  Workday started out betting on Tidemark, but things didn’t work out (I’d guess because of Tidemark’s wandering eye and lack of focus on EPM), so they switched horses to Anaplan.  It happens.

But then it starts to get more interesting:

  • In January 2015, Tidemark COO Phil Wilmington leaves Tidemark (per his LinkedIn).
  • In mid-June of 2015, Workday announces leading a $25M round in Tidemark, rumored to be under fairly Draconian terms, including some non-trivial layoffs to cut the burn rate.

OK, it’s more confusing but it still looks explainable from the outside.  After switching horses to Anaplan, perhaps they found the grass wasn’t any greener, so they decide to switch back.  People get divorced and then remarried.  It happens.

Maybe Wilmington influenced things and was trying to help out his old company, or maybe he had nothing to do with it.  It’s impossible to see from the outside, but at the same time hard to believe he had nothing to do with it.

But then things get even more interesting:

  • Two weeks later, on June 30 2015, Workday announces its own “enterprise planning, budgeting, and forecasting” solution, a seemingly independent initiative without any reference to Tidemark’s technology in the announcement.  Moreover, it appears to be a a hurried, deep future announcement with availability specified sometime “in calendar year 2016.”
  • Even today, almost 2 months after the announcement, the “Learn More” link on the products page for Workday Planning points to the press release, in an actual circular reference from the press release to products page — something I can’t recall ever seeing before in my career, and certainly implying both a hurried announcement and a lack of meat to support it.

cap2

What’s going on? Who knows?  (I have a guess and maybe I’ll share it one day in a separate post.)

But regardless of the underlying stories, the whole situation says a few things to me:

  • It’s another demonstration of why ERP and EPM are different categories.  Even a highly sophisticated ERP vendor like Workday can’t get its EPM strategy right.  It’s a different market, with a different buyer, with a different purpose, and which uses different and specialized technologies.  This pattern existed in the on-premises days and has continued into the cloud.
  • As such, it validates the desire buyers may have to go best-of-breed and buy EPM from a dedicated EPM vendor as opposed to expecting to see a great solution rolled into an ERP suite.
  • Most importantly, Workday’s pattern suggests it will be years before their EPM strategy is clear, their in-house product is delivered and proven, and whether the final strategy rides on their in-house product, Tidemark’s technology possibly picked up via a future acquisition, or some hybrid thereof.

Let me conclude by reminding anyone interested in doing EPM functions — like planning, budgeting, forecasting consolidation, reporting, and analytics — against Workday data, that at Host Analytics we have a clear strategy for Workday customers who want proven, cloud-based enterprise performance management (EPM).