Hello,
100+ modules, in and of itself doesn't sway me one way or the other. In most models, regardless of the number of modules, there are a handful of workhorse modules containing the most complex logic (or otherwise taking up the most space and/or resources). Therefore, the number of modules isn't determinitive.
I typically will separate (an activity or activities) into separate models based on the following factors (in no particular order):
- Data Loads - If a model is properly performance-tuned, but is still very large, I will consider opportunities to break an activity or process out into a separate model if it will improve end-user experience.
- Multi-user environment - If the user count is very high, I'll consider ways to break models up into logical buckets (this is often related to activity, but can be based on user groups also).
- Logical groupings to simplify administration - I work with FP&A models. Its happening more and more that we view the various FP&A activities (for example, Revenue & COGS Planning, Workforce Planning, Opex, Capex, etc) as independent activities that we may choose to split into separate models. More and more, clients want Workforce managed in a separate model. The chief considerations here include: the amount of data, the number of concurrent users, how we expect the model to grow over time (lists and users), customer preference, and complexity of the individual processes.
- User Experience - This is really important. What good is a model if users struggle? For smaller FP&A builds, I like to keep the entire process in a single model so that users can see their full budget/forecast roll-up real-time. Also, having all of the process navigation in a single model (in my opinion) makes things easier for end users.
Let's see what others have to add!
Paul
