'Systems Thinking' needs practice. Do not expect it to be easy at first. Build your skills with systems of increasing complexity, after a while it will seem natural. Systems thinking tools can be applied productively to lots of situations – so the investment in building your personal toolkit will pay off.
Analysis of the 'system-as-is' should be distinguished from design of the 'system-to-be'. You may interleave these, indeed you may implement changes in the system-as-is as an exploratory and learning tool leading you to the system-to-be, but you need to keep the distinction clearly in mind. Good analysis of the 'system-as-is' is often hard. This is a reason to do it, rather than a reason not to do it. The harder it is, the more it needs doing.
Interrogating the most basic question - ‘what is this system intended to do?’ - can help enormously in framing your approach. Do not shortcut it.
Think really carefully about system boundaries - what is part of the system and what is in the environment that may change and affect the state of the system. To draw this boundary you need to know your domain of action, what can you alter and what lies beyond your ability to change directly.
Set out the 'shared phenomena', these are the events shared between the system and its environment that precisely define the system boundary. Your system can only see or act on its environment by way of these shared phenomena.
Your best friends are 'abstraction', systematically suppressing detail, and 'information hiding', controlling the exposure of essential information through an 'interface'. This is not a technical skill as much an ability to simplify and resist the temptation to show everything you know. The best systems thinkers are the best simplifiers.
You are going to need to build models at some point. A model is not, repeat not, a picture. You have to be precise and make explicit choices of what to include in your model and what to exclude. A good choice of modelling scheme will provide you with valuable analyses. Often very simple modelling approaches (objects and relations, states and transitions, processes and flows) used with care will give you a lot of insight into a system.
Systems exhibit dynamic behaviour and some of their most important properties derive from this. Unless you understand the dynamics you do not understand the system. Check out feedback loops and delays.
Systems have a 'lifecycle', they are commonly implemented, initiated, operational, maintained, decommissioned, disposed of, and so on. In each phase of the lifecycle the principles of operation are different and must be understood, as must the transition between phases.
You are going to get in a mess if you do not think up front about how you are going to communicate, share and assure the results of your 'systems work'. I guarantee inconsistency, version problems and general confusion if you fail to set yourself up properly. You will need to keep the results of your systems work up-to-date for the life of the system, through ongoing changes and evolution. It is a vital part of your system management toolset. Just saying.
[Credit: Claire H again!]