This principle originates from the first half of the 1900's. The name is self-explanatory. The idea is to make processes as easy as possible to understand.
See this wikipedia article for a deeper into the overall concept.
You should aim to simplify everything you can. There is likely a lot of things that are more complicated than they should.
Building tools to help can be part of that process. Yes, building the tools may not be easy, or simple. But the outcome you get should outweigh the inconveniences.
What if you could get all the data you need to make your decisions on a single dashboard instead of multiple websites. What if you could automate some of your actions instead of relying on humans performing lengthy repetitive tasks.
Think about all the different ways things could be simpler. Tasks can be hard because they are inherently complex or because the process the process to follow is cumbersome. Can you break things down into smaller more manageable units ? Each of those can likely be broken down even further if needed.
Keeping things simple can mean start and stay simple or simplify things. Make your future life easier when you can.
A way to get there it to split each process into its sub-processes (recursively). Each unit becoming self-contained, easy to work on. The more granular you get, the better it is.
But, don't overdo it, especially at first. It is easy to get stuck on making things as great as they can be, thinking every use case, every issue you can encounter, ... But, it is likely not needed.
Spending too much time architecturing and splitting the program will distract you from getting the quick results you should be after. Build something good enough that works and improve upon it.
The approach I like in most cases, is to have a base working. One block with each part is well defined. You will need to identify what are the various components are. Then, treat each part one by one, limiting the dependencies between each as much as possible. The goal there being to get the original tool working in a clean way. Later on, when needed it, you can split things more, into different components that fit your new needs.
It is a delicate balance to find, between having something messy that works and something extremely clean that also works and is great to maintain.
Start first with something good enough. It may be a bit messy but works as expected, then build upon that as needed.
Let's take a simple example. Let's imagine you want to build a web page containing a list of event in your city, coming from 2 different websites.
Initial way to do it could be a script that:
That will work, however, you may quickly find that there are a bunch of drawbacks to that solution, from performance issues to maintenance.
So, you may end up deciding on breaking it like this:
That would take care of some of the issue and with the separation of concerns, it becomes easier to know that if you want to change the colors, you just need to go to the rendering part, that unit becomes much smaller and understanding/updating it becomes easier.
Later on, you may realise that you went from the 2 source websites to 10+ and the process takes too much time to retrieve the data. Another pass at it may lead you to splitting the general data retrieval script into 10+ ones, one for each source that you could run simultaneously. That becomes much easier when the web page rendering isn't a problem to deal with.
Also, what if you know want to send a daily email with the new events ? Same thing, having split the event retrieval somewhere else, you don't need to rewrite it. It just becomes a new rendering process.
Reworking the processes is also a way to find inefficiencies, things you can improve, remove or adjust to fit the current state of your business.
Even though the last version is the way to go, don't aim for it initially, aim to get things working. That's the most important thing. You can't predict everything, especially when getting started, so don't try to at first.
Avoid duplication and reuse the blocks you already have when you can (that may involve breaking down other processes first).
Then improve on that.