Don't found a company unless you love Excel
ekoester.com
ekoester.com
Invalid point - you need Excel to figure that out. I think a good hacker is more likely to use some combination of R, Python + Pandas, databases and CSV files to do most of their financial modelling. Then those all-important month-end reports can just be automated away...
Invalid point: Formulae are easy to follow and audience can easily verify/reproduce your work.
My friend, excel rocks when MAKING a spreadsheet, but it can be hellishly annoying to follow. when you got a long chain of formulae cells, it is very annoying to trace the data through it to see where it is coming form. Sure, a properly labelled Sheet takes care of it, but that's not usually the case. That's the main reason i am very excited about that excel-sheet visualization tool posted here the other day.
PS I'm also very excited for that tool. Will make my life so much easier.
>> Invalid point: Formulae are easy to follow and audience can easily verify/reproduce your work.
Actually this is another valid point of Excel.
Unless the financial model was done incorrectly (using VBA, complicated formula chains, unclear logic), it is very easy to verify financial model in Excel, which is a big plus.
Your spreadsheets would be big because of quantity of different things included, not because of complexity of those things
This is very structured data, you can build up hierarchy trees in python, but it will take you too long. Plus, your models will change, people will want to see things from many different changing angles.
Unfortunately, every time I start writing about controlling people desert the thread around here, but it is a fascinating topic.
What a spreadsheet does very well is allow you to quickly run a large set of simulations right next to eachother for comparison. This can be useful in asking questions like, "if we charge $x, and we have $y in fixed expenses, what should our target of support personnel to customers be?"
I usually use spreadsheets only as data entry software and then R does the rest.
You definitely can do it in R, but the formulas are trivial anyway and writing them in code takes as much time as in Excel, can you help me understand what I could gain by using R here?
When I worked in Wall Street level finance, basically none of the analysts bothered to use anything more than cell address, e.g. /[A-Z]\{0,1}[0-9]\{0,3}/. They basically treated naming their variables like most software engineers treat commenting their code. That shit was impossible to follow because.
The individual formulas may be trivial, but when you have a complex model with many pages representing different aspects of the business internally and external macro aspects, it can get messy fast.
This looks promising: http://wiki.openoffice.org/wiki/R_and_Calc
What a spreadsheet gives you, assuming you have enough math skill to operate one reasonably (i.e. at least a year of college algebra), is an ability to create tables of data following certain assumptions that project various scenarios. This is most helpful as a visualization tool. You could probably do something similar with R and some CSV files, but I find spreadsheets are actually really helpful here.
PS, I really don't like Excel, just because I have run into so many braindead issues with it. That doesn't say spreadsheets are not a very good tool for certain kinds of problems though.
PS: I think excel probably has some support for monte carlo too. should look into it.
If you want graphs you can spit out not just one, but multiple representative ones, credible intervals, etc.
First because the probablity distribution itself would have to be pulled out of thin air, and make the results questionable.
Second because writing the assumption->outcome formulas is simply quicker than running an MC sim even if doing the sim is a one-liner (simply ensuring that the data is in appropriate format and testing once will take longer than needed).
Third (and main) because you don't particularly need the actual outcomes at all, the hands-on-tweaking of these assumptions and 'interactive learning' is the whole point of doing it all, you need to personally learn and feel the relation between these assumptions and financial results, and the 'result' numbers and graphs are just a side-effect and notes/docs to remind you later.
And if you need to convince someone else afterwards of your conclusions, then for 99% of audiences you anyway want to use 'specific plausible scenario story' (or comparisons of such scenarios) instead of a probability distribution coming out of a solid mathematical simulation of all possibilities; since it's well researched that the first kind of evidence works better in convincing homo sapiens about anything at all.
Of course. It's just a more systematic version of manually tweaking parameters in a spreadsheet (which are also pulled out of thin air).
With libraries like PyMC, it's one extra step beyond writing an assumption->outcome formula. You write the same formula, but then set variables to probability distributions rather than floats .
And if you need to convince someone else afterwards of your conclusions, then for 99% of audiences you anyway want to use 'specific plausible scenario story'...since it's well researched that the first kind of evidence works better in convincing homo sapiens about anything at all.
Fair enough. This is solid dark arts, but useful.
Convenience matters in such things, and simply reading a 20x20 data table into any programming language already takes more time than just writing the formulas next to this table in excel.
outputs = []
for x in monte_carlo_input(param1_dist, param2_dist, ...):
outputs.append( (x, f(x)) )
histogram/whatever(outputs)
> f(10, 3, 0.07)
12
> f(12, 5, 0.09)
-3.9All aspects of financial forecasting in the initial stages are pulled out of thin air and are hence questionable. This is one of the big uncertainties one lives with when starting a business.
> Third (and main) because you don't particularly need the actual outcomes at all,
Bingo. That's the key. What you are looking for is not "will my business succeed" but rather "what do I have to do in order to succeed?" The tweaking of the model is the point, not the outcomes.
However, proper tool does make things more efficient. Based on practical experience Excel is excellent for financial modelling.
As for R, Python + Pandas, databases and CSV files - they are mostly useful for supporting and ad-hoc analysis, esp. for sales and marketing data.
Anyway, based on my current employer, spreadsheets are for:
Holiday rotas
Support call logs / case management
Weekly status reporting (because the format I was using in Word was so tabular 'it might as well be done in a spreadsheet' - go figure!)
Project Management (Make a GANTT chart by colouring in various width/Joined cells) and then spend ages manually adjusting things when dependencies slip.
Manually copying/pasting data from an on-screen query so it can be sorted and deduped before being put into an email. I have now automated the whole process.
More seriously, Excel has many problems that make it unsuitable for anything that might require statistical analysis. See for example B.D. McCullough and Berry Wilson, "On the accuracy of statistical procedures in Microsoft Excel 2003," Comput. Statist. Data Anal. 49 (2005), no. 4, 1244--1252, available online at http://dx.doi.org/10.1016/j.csda.2004.06.016 but paywalled. I thought that this article, or a similar one, was recently discussed on HN, but I could not find an appropriate link.
On the other hand, I don't know anything about business. I can see an argument for using a widely-deployed piece of software for verifying R > E even if it is inappropriate for data analysis.
In business usage, all your financial spreadsheets including forecasts will have a grand total of 0 statistical functions used; and your marketing/customer segmentation people, when a business starts to have them, will use some statistics but again, looking at your article (somehow not behind a paywall?) - there is zero overlap between the listed problems and with what those people will actually use.
Good analysis of customer behavior (instead of just financials) can use all kind of heavy stats, but it's done by different people and at an different company stage than the original article is talking about; if you're starting a company you simply won't be doing any of that until after a million of other things.
This does not mean that a spreadsheet couldn't be an important piece of the pipeline though. Database to Spreadsheet is actually a very powerful combination, particularly with views.
I worked at a company where our data was in SQL Server but we basically had to import the entire data set into Excel because none of the higher-ups knew SQL and wouldn't be able to peer review. Those spreadsheets were slooooooow.
It's funny, the other co-founder of Efficito is a financial analyst who writes tools to do his analysis for him in Lisp. He also maintains a Common Lisp implementation. Fortunately I bet your former employer would not be interested in his services.
It includes some code snippets and screen shots of hybrid Java/Lisp programs. He is also a maintainer of Armed Bear Common Lisp.
And practically everywhere else, that's why we're not writing web apps in assembler.
A. Because most developers aren't anywhere near familiar enough with assembler to do so and because ruby/python/php/etc are much much easier to use for developing a web app.
No Excel in sight. The only thing we use Excel for is client calculations and holiday tracking.
But why would you need this? You can do financial model in 1 hour using Excel...
But what the article is about, in a growing startup or a changing company (say, completely new product line) the 'one master source of data' is not in a database but the assumptions in your head; and any clever model based on your historical data will be either impossible or far more wrong than a simple order-of-magnitude calculation done on a paper napkin. And, well, Excel is more convenient than the napkin.
I say that as one of the factors in a VC company I worked for going bust was that they used some dodgy spreadsheet as part of it accounting system.
However, it is a huge mistake to keep your general ledger or book of original entry in Excel. The reason has nothing to do with making mistakes or errors and every thing to do about fraud. Paper is the gold standard in anti-fraud accounting systems, particularly if you follow the standard rules like ensuring books are kept in pen. Paper to Excel is fine. Replacing the paper with Excel is not.
Sorry, I could not comprehend the second paragraph.
Fraud has nothing to do with paper or computer based system. To minimize risk of fraud you need to implement proper sets of controls, like segregation of duties, etc.
As for Excel - Excel is a poor instrument for doing the accounting, therefore it shall not be used ... unless you have some kind of micro/nano business.
Well, let's see.
1. Preprocessing data for entry. This might be used, for example, if you want to depreciate fixed assets using a method your accounting software does not support.
2. Post-processing data. You might do this if you have a report from an accounting system but your final report needs to take into account additional factors. Some of my customers use Excel to turn trial balance data from their accounting systems into financial statements.
Another example of post-processing might be if you take aggregated sales reports from an accounting system and further process it by business folk who don't know the programming environment.
As for paper: Yes, separation of duties is a part of it but paper has an advantage that no computer system can match, namely that if you keep your books in indelible ink, then alteration of numbers is obvious on audit. This is a weak point of electronic media. You can lock it down, but it is always possible for someone to unlock it. So with comparable policies, paper wins out anti-fraud-wise.
>> 1. Pre-processing data for the entry.
For this specific example if the accounting package does not support certain depreciation method (which rather rare), you can easily do this in Excel, both for financial modelling purposes and as a supporting document for the accounting entry.
>> 2. Post-processing data.
What you describe is not accounting. This is financial and management reporting. Yes, Excel is what is used by most everyone.
Good points.
I estimate around 80% of the problems with our system come from using Excel to upload data.
What you need is:
- understand your numbers, which requires knowledge, brain and a bit of experience;
- accurate numbers, which shall be output by accounting.
You can prepare P&L forecast for $50-100M business on one piece of paper, if needed. Excel just makes things more efficient.
If you want to save, share, or reuse anything, though, it's a one-way ticket to versioning hell, and you need to run scheduled reports off a database.
Excel gets really dangerous when people who don't know anything about databases try to use it as a database.
If these needs aren't met by current accounting / finance packages, it definitely opens the door for a new competitor.