To all Modano users,
I have a broad and philosophical question for you all.
What general principles do you apply when deciding whether to develop within a single module or split out into multiple, separate modules. I realise that specific cases will dictate the answer to that, but I am after a more general thought process. As an example, what would you do if you had multiple revenue streams, each with their own set of unique drivers?
I find that at times, separating into multiple modules can reduce efficiency as you need to consider and setup the link-outs and link-ins. Other times, building within a single module can also reduce efficiency where changes are required and the area in question has not been isolated (via modules).
Discussion is welcome!
Regards,
Tony.
Your timing is very apt Tony, as I was discussing this with someone just yesterday...
We coined the term 'single module workbook' to loosely refer to an entire financial model that contains only 1 non-time series module. Such a workbook still provides the automation benefits of categories, time series, styles, consistent formulas, etc., but does not - as you note - require any understanding of module links. So, for people used to using native Excel, there's minimal relearning required before they can customize such a model.
On the face of it, using a single module workbook sounds great, but the dicussion quickly turns to where the main benefits of Modano come from... Do they come from automating repetitive tasks (like adding categories and extending the time series) or from being able to reuse and share modules and combine them different ways.
Another consideration is that there's a whole bunch of things - like creating scalable multiple business unit models based on mirrored modules - which are not possible when using only one module. So, for advanced users, its often not an option.
I'm very interested in this discussion, but my personal position is that a single module workbook would be a great tool for educating new Modano users about time series and categories automation, without over-complicating it with module linking complexities. However, for advanced users it's hard to understand why you wouldn't want replaceable, duplicatable, mirrorable modules throughout your models whenever possible.
Great question Tony.
My preference is to break it down into multiple modules rather than sticking to single or fewer larger modules.
Apart from then not being able to re-use or share those modules with others or for new clients, back in the day of BPM Modules I created proably one of the largest singular modules and it became problematic (this may not be the case with Modano, but it taught me a valuable lesson then).
In my opinion the mirroring of modules I think it possibly the biggest benefit of the system from a scalability perspective. It's like taking a formula 1 car and then adding on nitrous oxide. Its truly insanely quick.
Happy driving !
Thanks for the input guys.
I should clarify, my question wasn't wether we should modularise a model or just contain it all within one module. I'm wondering what thought process other Modano users have for deciding to split something even further, to even more modules.
Let's take revenue as an example, which is typically a single module. How much depth would it need before you decided that it would be better to split the revenue out into multiple modules?
Regards,
Tony.
I tend to keep my modules as large as possible, and only split into multiple modules for three reasons:
I don't generally create my modules generic enough for re-use, hence this advantage of Modules is not something I generally consider when designing models, and the benefit of being able to use inputs embedded in functions on other sheets is of a greater benefit to me.
That being said, I am the in-house model developer where I work and each model is normally quite large (3-6 month build time) and therefore bespoke. If I did work for multiple clients on smaller, less complicated models I would probably create smaller, more specific modules to enable re-use.
Cheers
Tarjei
That's an interesting comment Tarjei.
We've recently summarized the practical benefits of Modano as falling into 3 broad areas:
To date, we've really been promoting the modular development component of the automation area, but it's becoming clear that this really under-sells many of the other things Modano automates to improve model build quality and reduce time and risk, including:
All of these things can me automated while building a modular workbook as a single mega-module, which is absolutely fine if you're not creating modules for re-use or some other purpose, such as mirroring as you note. And it prevents the need to factor in the idiosyncrasies of module linking too!
It's yet another example of how everyone has different touch points when using the platform.
Coming back to this thread - is it appropraite to have in a business unit model a revenue module in the forecast sheet and then a second revenue module for a different product group?
I.e.
Business Unit 1 - Trading Coy
Revenue module 1 = cotton,
Revenue module 2 = Barley
COGS module 1 = cotton
COGS module 2 = barley
Operating expenditure module
What would the complications of this be later or as long as I get the links right this should be okay?
Hi Blake,
I believe the new Business Units contents allows you to model individual Business Unit revenue (and other) lines with different driver modules per line per business unit. The business units have separate historical financial statements, so you just need to make sure you maintain the categories. This should be simple if importing, as the import will trigger an alert for a new category, but if you're forecasting with a placeholder category, just make sure it's included in every Business Unit that requires it.
One thing to consider is dealing with shared costs that are calculated centrally, which commonly arises with calcs like Leave / Payroll Tax / Super, etc. If these need to be allocated out, you'll probably need to customise the content to manage this.
This is the same thing to consider for items that are driven off a balance sheet item like Depreciation / Interest.
Hope this helps.
Jun
Yes guys this entire thread has been impacted by the fact that our new variable drivers structure uses a separate module for each category of revenue and expenses (and other balance sheet items), so you can have any driver for any category...
It's worth checking out these videos to understand this stuff:
It's very versatile stuff, so unless you've got a very bespoke business you should be able to do most things just changing drivers and adding/removing categories, without manually handling links or inserting modules, etc.
Let me know if this isn't what you were after.
Michael
Follow up question then - I oriignally went a Variable driver module and then see the alternative driver revnue model with X would be better - is it easy to replace or a no no swapping between types of driver models?
To clarify - can I have a hybrid model with some variable drivers modules and some non-variable? or would this bring bad juju?