databill86 · April 7, 2020 12:56 · Nov 7, 2016
diff --git a/Capacity Planning Problem Definition.md b/Capacity Planning Problem Definition.md
@@ -0,0 +1,56 @@
+Following on from a meeting with Simon, Ed, and Bryan. It seems like
+we’re trying to answer two questions:
+
+* Where are we overloaded?
+* What aren't we using? (That we should look to find or fit work to.)
+
+Different contexts:
+
+* Managing current load
+  * Always starts with released shop orders.
+  * Would typically also include planned shop orders and requisitions.
+
+  Asks questions like:
+  * Which work centres are overloaded? When? How much?
+  * What is the load? (Released orders, planned orders, reqs, etc.)
+  * When can the load be re-scheduled on the same work center?
+    (Can the load be pulled forward or pushed back? How much by?)
+  * Can the load be moved to a different work center? Which? When?
+    (Identify alternates by production line.)
+
+  The trouble here is that the more questions you start asking the more
+  you realize that you are duplicating the work of a finite scheduler.
+  Ultimately that’s what the goal appears to be: manually finite
+  schedule those areas of the infinite schedule that indicate a capacity
+  constraint. Surely we should just invest our energy into getting a
+  workable finite schedule instead?
+
+  Wherever possible we should quantify the load in human terms such as
+  days, weeks, "shifts", etc. and not merely in pure numbers of hours.
+* Planning for future load
+  * Forecast based
+
+Aspects:
+
+* Production lines
+* Customers
+* Projects
+* Standard Names?
+
+## Work Centers with Interesting Consumption Patterns
+
+* MC027
+* MC028
+* **MC040**
+* MC068
+* MC273
+
+## References
+
+* http://www.perceptualedge.com/articles/visual_business_intelligence/displays_for_combining_time-series_and_part-to-whole.pdf
+* http://www.perceptualedge.com/articles/visual_business_intelligence/building_insight_with_bricks.pdf
+* http://www.perceptualedge.com/blog/?p=2239
+* http://flowingdata.com/2015/07/02/changing-price-of-food-items-and-horizon-graphs/
+* I can’t shake the feeling that a heat map might be useful:
+  * http://bl.ocks.org/tjdecke/5558084
+  * http://bl.ocks.org/mbostock/4063318
diff --git a/Thoughts on Scheduling and Capacity Planning.md b/Thoughts on Scheduling and Capacity Planning.md
@@ -0,0 +1,199 @@
+Thoughts On Scheduling and Capacity Planning
+============================================
+
+In all cases we can assume that we have _n_ jobs to schedule across _m_
+(> 2) resources with multiple, sequential, operations utilizing
+different resources to perform per job.
+
+As a rough guide we have ~150 resources (active internal work centers)
+and ~2000 shop orders with ~21000 operations to schedule. Slightly under
+half of those orders are planned (~900) but as at the time of writing
+account for only a third of the operations (~7000.)
+
+There are an ~300 unconverted requisitions which could account for ~3200
+more operations.
+
+So, this is already a large dataset without the addition of multiple
+customer forecasts.
+
+## Infinite Scheduling
+
+Generally quite simple. The only constraints are the sequence of
+operations _per job_, resource availability (non-working times), and the
+maximum number of hours per operation on each resource.
+
+It’s also a task that is easy to parallelize as each job can be
+scheduled in isolation.
+
+Both backward and forward scheduling are equally valid and can be mixed.
+
+Different job sets can be easily, and commutatively, combined using
+standard aggregations.
+
+The data is fairly static and there is minimal “churn” resulting from
+new loads (or changes to existing loads) as there is no interaction
+between jobs.
+
+There is no definite requirement to re-schedule jobs due to the progress
+of time however it would almost certainly be useful to be able to both
+see which jobs are overdue (have operations scheduled in the past) and
+to forward schedule them (being advised of the new finish date.)
+
+Additional data provides no real utility. This isn’t so much a
+scheduling algorithm as it is an _aggregation_. Details of alternative
+resources, for example, have far more utility when interpreting and
+acting upon the results of the schedule than they do during the
+scheduling process.
+
+### Outcomes
+
+* Overdue indication for jobs (when backward scheduling if an operation
+  is scheduled earlier than the current date then there is no means of
+  achieving the required date, likewise if forward scheduling and the
+  order does not finish before the required date.)
+* Resource over subscription (at potentially varying levels of detail.)
+
+Essentially all an infinite schedule will give you is a heat map of
+where your current scheduling results in resource over loading. This
+could be produced at varying levels of detail both in time (daily,
+weekly, etc.) and resource grouping (per work center, production line,
+department, etc.)
+
+This can then be used to manually adjust the loading by either altering
+the assigned resources, changing the target dates, or modifying the
+characteristics of the load (run times, etc.)
+
+## Finite Scheduling
+
+By far the harder of the two problems and generally considered to be a
+NP-Complete problem. Your results will always be an estimate and never
+an “optimal” solution.
+
+[Genetic Algorithms][GA Scheduling] are particularly well suited to
+providing solutions and provide significant opportunity for parallelism.
+Constraint or Logic based programming also provide useful frameworks for
+writing scheduling algorithms.
+
+Forward scheduling is by far the more sensible approach. Backward
+scheduling really doesn’t make a lot of sense.
+
+Different job sets can’t be combined but must instead be _layered_:
+using the calculation of one set as an input/constraint for the
+calculation of another.
+
+Most changes to the input data will require significant if not total
+recalculation. Something as simple as changing the resource assigned to
+an operation or its run time will have significant knock-on effects.
+
+The result _should_ be recalculated periodically in order to stay
+relevant. Once per day would probably be sufficient.
+
+Finite scheduling is better suited to running against multiple
+constraints such as both machine and labour availability. If you are
+only interested in modeling a single set of constrained resources (i.e.
+work centers) then an infinite schedule satisfies the 80/20 rule and
+requires significantly less effort. However, as the number and
+complexity of constraints increases so does the complexity of the
+calculation and finite capacity scheduling ceases to be more complex and
+so becomes the better model (as it produces more “accurate” results than
+infinite scheduling.) I would argue that this point is crossed by simply
+including labour scheduling alongside work center scheduling.
+
+Unsurprisingly then, finite scheduling benefits greatly from additional
+data that provides more specificity in the requirements and details of
+potential alternatives. The more data that is available to the
+algorithm the better the resulting schedule will be.
+
+### Outcomes
+
+* Easy to produce list of late orders.
+* Resource bottlenecks can be identified by average operation queue
+  time.
+* Provides the ability to produce accurate “best end dates” for new
+  requirements (due date quoting.)
+
+It seems like finite scheduling provides relatively little extra benefit
+over infinite scheduling given the very significant increase in
+complexity however accurate quoting at point of sale is practically a
+business imperative now.
+
+### Inputs
+
+Which we have:
+
+* Material procurement constraints (e.g. maximum lead time of
+  unavailable material for an order.)
+* Rough order priorities (weighted priority based on need date.)
+
+Which we don’t have and would improve the schedule:
+
+* Precedence of shop orders relative to one another (e.g. parent
+  assembly order to sub assembly orders.) Replaces order priorities with
+  exact sequence/dependency information.
+
+  This _could_ be derived from MRP but the lack of links between
+  supplies and their consuming demands in IFS necessitates producing
+  such data ourselves.
+* Potential operation overlap details.
+* Distinct setup and run times.
+
+Which would be required for scheduling labour:
+
+* Labour classes and employee assignments sufficient to provide the
+  “pools” of workers suitable for each operation.
+
+  An alternative that could be used would be to group employees by work
+  center based upon the work centers they’ve booked against recently
+  (e.g. the last six months.)
+* Actual labour run times for operations, distinct from the machine run
+  time.
+* Crew size requirements (e.g. for assembly ops requiring more than one
+  person)
+
+In reality there is nothing preventing us from scheduling against labour
+constraints at present. The above would all make the input data more
+accurate and therefore improve the quality of the schedule but none of
+them are required (except the grouping of employees and identification
+of group(s) suitable for operations but the work center based grouping
+would be sufficient to start with.)
+
+Scheduling labour would also require a change to how we view work center
+resource availabilities. At present the work center availabilities are
+based on a rough approximation of the _labour_ availability for that
+work center. A schedule derived from the constraints of _actual_ labour
+availability and the labour derived work center availabilities would be
+quite severely hindered in it’s utility.
+
+Therefore when labour is used as a scheduling constraint the work center
+constraints should be relaxed to better reflect their nature as
+machines/tools for the jobs. The only real constraints they impose is the
+number of distinct resources that are available (i.e. the number of
+concurrent jobs they can run) and periods of unavailability due to
+maintenance.
+
+## Glossary
+
+* “makespan”—the total duration of the proposed solution, from the start
+  of the first job until the end of the last.
+* “flow shop”—a scheduling environment of _n × m_ jobs where the
+  processing sequence is the same for all jobs.
+* “job shop”—a scheduling environment of _n × m_ jobs where the
+  processing sequence may be different for different jobs.
+
+## References
+
+* [GA Scheduling]
+* [A Genetic Algorithm for Resource-Constrained Scheduling](http://lancet.mit.edu/~mwall/phd/thesis/thesis.pdf)
+* [A Genetic Algorithm for Flexible Job Shop Scheduling](http://www.iaeng.org/publication/WCE2013/WCE2013_pp703-708.pdf)
+* [Evolutionary Search and the Job Shop](https://www.researchgate.net/publication/2485458_Evolutionary_Search_and_the_Job_Shop)
+* [“jobshop” strategies compared using Julia](https://github.com/stefan-k/jobshop)
+* [“jobshop” projects on GitHub](https://github.com/search?utf8=%E2%9C%93&q=jobshop&type=Repositories&ref=searchresults)
+* [Flow Shop Cuckoo Search Algorithm](http://posh-wolf.herokuapp.com/algorithm)
+* [“flowshop” projects on GitHub](https://github.com/search?p=1&q=flowshop&type=Repositories)
+* [Multiagent Optimization System](https://github.com/wiomax/MAOS-TSP)
+* [Genetic Programming in Clojure With Zippers](http://www.thattommyhall.com/2013/08/23/genetic-programming-in-clojure-with-zippers/)
+* [Watchmaker Framework for Evolutionary Computation (Java)](http://watchmaker.uncommons.org/)
+* [Genetic Programming Field Guide](http://www.gp-field-guide.org.uk/)
+* [Operations and Production Systems with Multiple Objectives](https://books.google.co.uk/books?id=tvc8AgAAQBAJ&printsec=frontcover&dq=isbn:9781118585375&hl=en&sa=X&ved=0ahUKEwikyITH7aHLAhXE7Q4KHWMpBOEQ6AEIHTAA#v=onepage&q&f=false)
+
+[GA Scheduling]: https://en.wikipedia.org/wiki/Genetic_algorithm_scheduling