Building a formal planning/scheduling architecture ...

We're working on a proper architectural framework for planning and scheduling in production organizations. It provides a coherent process approach for the various activities and time horizons related to planning and scheduling, and also serves as a basis for the use of our technology solutions.

Why bother, you may ask? After all, everybody knows (or can learn) how to do planning and scheduling, right? Well, what I often find when I am talking to organizations large and small is that there is no architecture or defined framework: the processes are entrenched, and have just evolved over time, to a point where they are difficult to manage, use a mixture of uncoordinated manual methods and software tools, and don't support future growth plans very well.

Below you can see an example (drawn from my discussions with many different organizations) of the kind of situation that I encounter.

The overall production cycle is fed on a yearly basis by production targets, budgets, resource constraints, and so on. Quite often, from that point things become messy. There might be multiple, different, planning processes in place (more than are on this diagram—I haven't shown turnaround planning, for example) which should operate in close collaboration, but which frequently don't (production and maintenance, anyone?). “Planning” may cover a yearly time horizon, or it may look ahead only three to six months. Sometimes there are intermediate scheduling steps which focus on activities between one and three months out, but sometimes there are no such steps. On a daily or weekly basis, there may be all sorts of groups with different processes and different tools, trying to collaborate, with a lot of communication going on (which sometimes gets very fuzzy). I've been in a room at a major production organization where people scheduled by yelling at each other and writing resource/task assignments on pieces of paper. While that might be appropriate in some places, it wasn't working very well for the organization in question.

The architecture that we've devised is shown below.

The overall process is based on the same corporate feeds as in the prior situation, but now we have three major process cycles that are linked and that provide for multiple time horizons: long term planning, mid-range scheduling, and short term operational scheduling and dispatch. Our technology handles all three tiers in this diagram, and we create a centralized database where all information is stored and available to whoever needs it, in whatever form they need it (for example, published on the web in read-only form). Long term planning can be done automatically, and various scenarios for activities and resource allocation can be created and evaluated for suitability. Once a suitable plan is created, it's stored in the database and available to the other processes in a seamless manner. Mid-range scheduling assigns resources to activities in an optimized way, so that organizational targets are met. Again, the results are stored in the database and available to all other parties in the plant. When changes and disruptions occur during the operational day, their impact can be assessed accurately, and various ways of dealing with them can be devised, so that the most appropriate course of action can be put into play.

We think that this architecture makes a great deal of sense. If you have feedback or comments on it, please feel free to plowman [at] actenum [dot] com.