Next section of this example -->
College Life: Is It a System?
The student's basic problem: within constraints that I cannot control, how much of my time do I allocate to which activities?
The goal is to see if the situation that contains the problem can be represented as a system ... if so, then I can use the system to test possible solutions to the problem.
Where I am: I have been given a problem. At this point I don't know if the problem can be solved, or if the problem even makes sense. So the first thing I have to do is to read the problem, think about it, talk about it, and make sure that I understand what the situation is and what I am trying to "solve".
What I do next: gather data and start to build a model of the situation. As you can see in the diagram, this will not be the final version of the model, and I do not expect to find an immediate solution to the problem. I build the model in order to make sure that I understand the situation.
Starting The Model
A systems model must include a collection of individual objects and/or processes that communicate with one another in such a way as to produce a network of connections. 
That is, each item in the system is connected to at least one other item so that the whole collection is fully interconnected. This network must be embedded within an environment ... that is, the system is surrounded by everything that is not inside the system.
The student's problem is how to allocate time to activities. The complication comes from the fact that the student cannot just arbitrarily decide what time to do things ... many of the times are set by others and cannot be changed.
Since the problem seems to be about scheduling, as a first try it would make sense to create a model schedule. This would make the environment contain anything that affected the schedule but was not an actual part of it.
This is easy enough to think about. The student has various things to do, and these can be identified. Notice that this first model is extremely vague. This happens because I do not yet know what I am doing. This doesn't bother me because I plan eventually to know a lot more.
The process of figuring out how to describe the problem is often what matters the most.
Assembling Data
Data about the student's activities now comes into play. For example, suppose I talk to a student and learn the following:
I can merge this data into my original, vague model. The upgraded model has a name for each event. And each event now has a color. (Neither the shapes nor the colors are required. But their use makes the diagram much easier to read.)
Some events are completely decided by forces outside the student's control. Band events are in this category. Band practice happens at a certain time, and nothing the student can do will change this. The star indicates that the event is controlled from the environment, and the red color indicates that it cannot be altered.
Some events are entirely within the student's control. The student can choose when to spend time with friends, for example. These events are colored yellow.
Other events are partly controlled by outside forces, but the student has some amount of input as to their timing. The student's employer establishes a work schedule, but the student can negotiate to work certain of these hours.
Classes are similar, in that the student gets to choose from a menu of different courses that meet at different times. These are not as open as "friends" time, but they are not as strict as "work" time. In this model they are colored like work but have no star. Different systems designers would choose to do this in different ways. (Some would add another color ... which to me would be confusing. And some would attach a star ... but I think class choice is a lot more open than work choice. You would do it in whatever way works for you.)
Checking the Model
Is it a system? Where is the networked interaction among the items?
In fact the relationships among the elements is one of exclusion. No two elements may occupy the same time of day. If one element is changed, all of the others must also change to reflect the new timing pattern. So the next logical step would seem to be to put the elements on a time scale. The scale organizes them and establishes their relationship to one another.
This is now beginning to look like a page from a scheduling book or a PDA app. But it is not one of these. The problem had to do with scheduling a student's time. But this model is not trying to design a working schedule. Instead, it is trying to come up with a way of thinking about scheduling that will help the student design his or her own schedule.
I have not reached that goal yet, but this is a good place to end this first attempt.
(This model does not look at all like the widely used "flow" model that was described earlier. I chose this problem in part to demonstrate that there is no preferred method of modeling. Large corporations or professional consultants will want to use exact, formal methods for constructing their models. But this is not required, and individuals should use whatever format best helps them understand the situation.)
Conclusion: Yes, This Situation Can Be Modeled as a System
This is just a preliminary conclusion, and there are still many questions:
These will have to be handled. But the purpose of this first section was to decide if the situation could be addressed as a "systems problem", and it looks like it can.
(For more on how to read and make systems diagrams, look here.)