An Innovative Real Time Production Management System

of 13
© 2013, Laxman C Marathe
An Innovative Real Time Production Management System
A white paper
Abstract
Scheduling is indeed a major issue in all manufacturing and project execution facilities world over. It is also
recognized that if scheduling is efficient and automated huge benefits could result as existing resource usage can
be maximized allowing dramatic increase in number of orders processed at the same time substantially reducing
cost of production while ensuring reliability in delivery on the committed date. No wonder scheduling is a hot
research topic and the market is flooded with scheduling systems of sorts. Still a truly efficient and automatic
scheduling system remains an elusive dream.
This white paper lists the six important reasons why a scheduling system fails in real-life situations. It then
describes how a new scheduling system called Talika PMS satisfies all the six critical requirements in detail with real
data supporting the claims from its first major installation.
Visit www.etalika.in for more information and free download
1 Introduction
Day-to-day scheduling of any manufacturing facility
is recognized to be the most important problem to
be solved. [1] D. Ouelhadj and S. Petrovic recent
[Oct 2008] study reveals that solutions based on
creation of a static schedule are impractical in real-
life situations and discusses several dynamic
scheduling approaches only to conclude that more
work is still needed in this field of research.
We wish to present here a complete dynamic real-
time micro level scheduling system that is proven to
work in the most complex manufacturing facilities. It
is a fully scalable, decentralized, multi-location and
user configurable system to suit any manufacturing /
project environment. The core scheduling is fully
automatic and guarantees that all currently allotted
tasks in real-time can be executed with a complete
and detailed schedule prediction of all activities for
all orders in-hand. The system automatically
reschedules in response to real-time events as
notified by operators’ handling current tasks on the
shop floor, with an objective to maximize resource
utilization while minimizing job cycle time. It offers
full micro-level future schedule visibility of all
running jobs to predict when each would be over
given the current load as of NOW. The cycle of
allotting tasks, seeking task-wise feedback on
allotments made from operators’ on shop floor, and
re-predicting its impact in subsequent reschedule
happen every minute 24x7.
Before we elucidate more on the system features we
would like to re-emphasis importance of scheduling
in any manufacturing facility and why current
solutions fail to address the problem correctly.
2 Importance of scheduling
The only real differentiators to compete in
established products and services market are Cost
and Reliable delivery. Quality of product / service is
mostly considered a pre-condition to be in business
rather than a differentiator. Both cost and reliable
delivery of product / service are directly impacted by
scheduling.
2.1 Scheduling and cost of production
It is almost axiomatic to state that a major portion of
cost of production (even exceeding 70% - 80% in
made-to-order industries) is expended in
coordinating and managing production activities vis-
à-vis the actual cost of value-addition involved.
Most real life manufacturing involves execution of
several individual activities in a complex order to
create any saleable final product or service. The
starting point thus is in breaking down an order
requirement into elemental activities that must be
completed in order to accomplish the final product /
service deliverable: ranging from getting inputs or
raw material until final packing and dispatch. Unless
this detailing is not done, actual value addition
cannot begin. Once it is known “How” the order can
be fulfilled the most difficult job of scheduling

of 13
individual activities of orders begin. It primarily
translates in deciding what activity must be done,
where it should be done (that is using what limited
resources) and when. One can refer to them as the
3W’s. Most expensive and competent personnel in
any manufacturing or project execution facility are
engaged fully in the process of managing production
that involves, breaking down order execution,
estimating its cost, time and wastages, deciding
what activities to do now and next, taking feedback
on progress made, follow-up and expediting to meet
deadlines. The whole exercise is repeated all over
again by rescheduling to predict and monitor
expected completion dates for all orders in hand.
Add to this already complex situation, the burden of
estimating when new orders can be delivered given
the existing load of orders already in-hand. All this is
now possible to be completely automated resulting
in a substantial reduction in the cost of production.
2.2 Scheduling & reliability
Scheduling decisions taken now directly impact
expected completion times of all orders in-hand. In
real-life situations one has to deal with several
orders, each with its own set of individual
interdependent activities requiring a certain profile
of resources that are both shared and limited. It is
well impossible, even in small setups, to manually
figure-out impact of real-time decisions on predicted
completion dates.
Honoring delivery on committed date is more
important than how fast one turns around an order
in a manufacturing facility. It is only possible to do
so, if one is in a position to predict impact of all
scheduling decisions taken now on all orders in-hand
in real time as an on-going process.
3 Why conventional scheduling systems fail in the
real world?
3.1 Static scheduling
Scheduling is a widely misunderstood term. Many
believe plotting activities to be performed on
different resources on a time scale (Gantt chart)
make a schedule. Actually a Gantt chart is just a
snap shot of what is likely to happen in the future
given the situation NOW. As one progresses in time
this representation will change because predictions
seldom match reality owing to unexpected
disruptions [3] & [5].
So, any scheduling system that fails to respond to
changing situation on ground by failing to reschedule
and redraw its prediction (Gantt chart) is a misfit in
real life making purported schedule optimality and
efficiency claims hypothetical.
3.2 No feedback mechanism
A scheduling system can only be responsive to what
is happening on the shop floor if a feedback
mechanism exists. This feedback mechanism should
be both real-time and automatic. Peter Cowling and
Marcus Johansson [2] argue in a well researched
paper that “in many production processes real time
information may be obtained from process control
computers and other monitoring systems, but most
existing scheduling models are unable to use this
information to effectively influence scheduling
decisions in real time”. This is a major disconnect
making the schedule infeasible as it is soon out of
synchronization with reality.
We have recognized that the only authentic real-
time source of feedback information from the shop
floor is the personnel (Operators’) in charge of
performing individual activities. However, each
operator can only give feedback on what each one
does and that too ideally limited to the current task
in-hand. We achieve a seamless feedback
mechanism to the scheduling engine by allocating
elemental executable tasks in real-time to individual
Operators, and seeking task-specific feedback for
each such allotted task. The process of task
allotment, progress feedback and subsequent
reschedule to decide what to do next happens 24x7
automatically.
3.3 Schedule not actionable
The decision to execute an elemental task or activity
of an order requires one to take into account several
aspects; availability of inputs, availability of
resources and technical feasibility of performing the
task. Most scheduling systems usually fail on this
count. Proposed activities are either not actionable
or represent a group of activities leaving the decision
of what exactly to do now to the operators. In order
to circumvent this problem, many systems offer a
“drag & drop” facility to correct or manipulate
proposed schedule before it is released. As [4] P.

of 13
Velaga asserts, presence of a “drag & drop” facility
indicate an inherent weakness of the scheduling
logic.
3.4 Manufacturing facilities are on-going concerns
Getting new orders and completing existing orders is
a continual process in real facilities. Existing
commitments cannot generally be disturbed because
of new orders. Situations can become more complex
as orders could be cancelled or amended. Any
scheduling solution that considers a static order load
is therefore impractical.
3.5 Working in shifts
Many manufacturing facilities work round the clock
in shifts manned by a different set of personnel.
Scheduling decisions impact across shifts and the
biggest challenge becomes information handover
between shifts. The only remedy is in having the
scheduling systems work 24x7 continuously.
3.6 Stability versus responsiveness
Most scheduling systems provide a stable schedule
frozen for a period (usually a few days) and expects
it to hold well unless disruptions occur, which
inevitably do occur. It is reasoned that having a
continually changing schedule results in shop floor
nervousness. Shop floor nervousness is a myth
propagated to hide inability of doing a quick
reschedule. Operators’ are only concerned with the
task in-hand. As long as the current task remains
unaltered any amendment to future task listing in no
way adds to nervousness. On the contrary, impact
on completion dates of all jobs in hand must be
known immediately not when the next frozen
schedule is created.
We propose a true scheduling system called Talika
Production Management System (PMS) that satisfies
all the above primary requirements.
4 Overview of Talika PMS
The system has a distributed architecture as
indicated in Figure-1. At the center is the real-time
scheduling engine working round-the-clock and is
the live heart of the system. Several different types
of consoles interact with the scheduling engine using
a proprietary protocol that is robust and
asynchronous making the entire process of
communication absolutely safe.
There are several different types of consoles each
designed to perform a specific function on the shop
floor. Consoles work in a standalone mode but can
also communicate with the scheduling engine, if
connected, making the entire distributed system live
and reliable. Exhibit–1 at the end details
functionality of each Console shown in Figure-1 and
explains how the automatic scheduling engine drives
other peripheral or support activities. Most ERP
systems only handle the peripheral activities sans
the driving scheduling engine at its heart, making it
more of a fancy carcass disconnected from the shop
floor.

of 13
Figure-1: Macro system schema
5 How the system works
Figure-2 gives an at-a-glance view of how the
entire system works.
5.1 Starting point
Job Study Wizard (JSW) is the starting point. As
already explained each sales person or
concerned agency can have a JSW of their own.
Potential enquiries can be quickly converted to a
detailed job definition depicted as an easy to
understand component task (CT) diagram. CT
diagram actually represents the micro level
activity work flow for creating one-something of
any value-added service or product. It is more
like a recipe. One can always scale it up or down
to match extent of final output required keeping
the CT diagram (recipe) unchanged. It is also
possible to create, as a one-time exercise, a
bank of most standard CT diagrams (standard
orders) used in the facility. So, defining new
orders may simply translate into picking up an
appropriate or nearly matching already defined
CT diagram and making minor adjustments to it.
One can also create part CT diagrams for
common work flows in the factory and save
them as sub-assemblies. Sub-assemblies are
building blocks one may use to quickly create a
new complex job definition.
Jobs are stored as proprietary files with a
default “*.tlk” extension to any media. One can
save, share and reuse stored jobs over and over
again just like a text file.
5.2 Scheduling a job
It is not necessary all defined jobs be actually
scheduled. Jobs could be defined when we
receive an enquiry to estimate its cost and
assess delivery date, but we only need to
schedule the order when it matures. When
scheduled, orders flow over to the scheduling
engine and the process of executing its
constituent tasks begin.
5.3 Role of scheduling engine and shop floor
interface: Work Center Console (WCC)
Scheduling engine works 24x7 and proactively
controls all factory work centers at a micro level.

of 13
It decides what tasks of which orders can and
should be actually allotted for execution to the
shop floor. Complete information of currently
allotted tasks flows to the concerned WCC in
real-time. Operators’ acknowledge allotted
tasks to start execution and notify interim
milestones achieved, until the allotted task is
not over. All notifications flow back in real-time
to the scheduling engine to be taken cognizance
of during the next reschedule that happens
every minute. This cycle of allotting tasks,
getting progress and completion notification
feedback, and subsequent fresh allotment on
each work center on the shop floor goes on
without end.
Figure-2: Working principle at-a-glance
6 Working logic of scheduling engine
Scheduling engine comprises of a set of complex
daemons working round-the-clock. Like a
human scheduler does, it always decides what
tasks to execute now. The entire optimization
principle could be summed in one line as “if
something (read a task) can be done and it
should be done then it will be done”. The above
rule automatically guarantees that resource
utilization is maximized while simultaneously
reducing job cycle time.
An order is first broken-down to its elemental
tasks in form of a CT diagram during definition in
the JSW itself. Only on confirmation, valid
orders are communicated to the scheduling
engine. During order definition stage itself a lot
of detailing about the job is done including de-
selection of technically non-feasible work
centers to execute specific tasks of the job.
User can also specify several guidelines for the
scheduling engine to follow while executing the
order called “execution preferences”.
Scheduling engine uses its own intelligence
while implementing user specified guidelines
but ensures they are honored whenever
possible. Execution preferences are not rigid;

of 13
they can be changed even at run-time after a
job is scheduled. Execution preferences could
be different for each task. However, user can
specify them just once with applicability
controlled across parts or group of tasks or for
all tasks in an order. Table-1 below lists the
execution preferences and explains what each
means and how the scheduling engine uses
them while making allotment decisions.
Table-1: Execution Preferences and what they mean
Execution preference What it means Scheduling engine usage
WIP control
Attempt to minimize work-in-
progress (WIP) from being
created too much in advance
and thus remain unused.
If WIP is not on the critical
chain and has enough time left
to be produced and used then
its creation is deferred thereby
minimizing WIP build-up on the
shop floor.
Control of task
execution order
User desires to change task
execution order, if necessary, at
run-time.
Tasks are allotted first by order
priority and then by the future
burden on the task within an
order. However, user may
change this natural order of
execution at run time.
Work center choice
If one has a choice of work
centers to perform a task then
which one to choose?
Scheduler tries to honors user
preference with switchover
savings, if any, considered. In
case the first preferred work
center is unavailable it tries to
allot the task on the second
preferred work center and so
on.
Locking Option
Ensuring a particular task is
only executed within a user
specified period.
Always tries to execute the said
task within the specified period,
as far as possible.
Auto-breaking option
Breaking up a task to run
concurrently on more than one
work center with an intention
to reduce task execution time.
If the task is on the critical chain
or its execution cannot be
deferred any further scheduling
engine will try to optimize and
select the most appropriate
breaking option possible.
Spanning Option
Stop and resume task execution
after a holiday, recess period.
Commonly referred to as a non-
scheduling time zone (NSTZ) in
the system.
Scheduler wisely decides to
span or not to span depending
on the current situation.

of 13
MCI option
It may not be necessary to wait
to start the next value-adding
task that uses or consumes
what is produced by the current
task until the current task is not
over. One can overlap in time
both tasks in order to expedite
the order. We can say the
preceding task gives a mid-
course intimation (MCI) to the
next task to begin.
Scheduler tries to begin the
next value adding task even
before the earlier one feeding
into the next one is not yet
over. Time to initiate the next
task can be user decided or left
to the scheduling engine to
figure out.
Interleaving option
User may want some tasks
(orders) to be executed only
when there is free time
available. Contrast this with
auto-breaking where the
objective was to expedite.
Scheduler ensures the task is
executed whenever there is
nothing urgent to be done.
MCF Option
Especially in long running tasks
interim milestone reached
feedback may be necessary to
re-adjust expected task
completion time. We call it a
mid-course feedback (MCF).
MCF is used constructively to
adjudge the expected
completion time for long
running tasks.
NSTZ cut-in option
NSTZ is an acronym for non-
scheduling time zones. Periods
when the scheduling engine will
not schedule (allot) a fresh task.
However, an already running
task can either by design (or
because it is delayed) cut-into
an impending NSTZ. System
supports five categories of NSTZ
with varying importance and
user can define how much a
particular task can actually cut
into each of them.
Scheduling engine takes
appropriate decision to cut into
NSTZ whenever necessary.
Working during NSTZ is an
additional cost and calculated
accordingly.

of 13
Task line-up
It is possible for user to specify
that in an order if some task A
is executed on a particular work
center then preferably task B
too should be the next one
followed by task C and so on.
Valid reason could be
substantial saving in cost and
time if done so. We call it task
cascading. This again could be
a preferential cascading or a
forced cascading when user
insists that the scheduling
engine waits a pre-determined
period for the next cascaded
task to mature for execution.
You can guess concept of
cascading is different from
controlling task execution
order. The former is applicable
within an order whereas the
later could be across orders and
typically is a run-time user
intervention.
In addition to above user specified execution
preferences, the scheduling engine takes into
consideration several other aspects as well and
does its own run-time adjustments as listed
below.
6.1 Work center capacity
Checking if it is possible for a given task to be
executed on a work center must be done before
each allotment. Our system allows user to
define multi-part work centers that could either
work as a whole or in parts enabling one to
execute a variety of tasks each requiring it own
part capacity profile.
6.2 Activating work center
Resources and work centers are conventionally
thought as synonyms, but in our system a
resource has a very special meaning: a work
center to become active requires resources.
What resources are required to activate a work
center is user defined. Therefore, if a work
center is currently not active it is necessary to
check for resource availability. Task allotment
can only happen if it is possible to activate a
work center. This check is done automatically
by the scheduling engine.
Activating work centers could also be dependent
on capacity usage. A typical case could be an
industrial oven that is uneconomical to be fired-
up unless filled-up to some predefined minimum
capacity.
6.3 Considering time for material movement
and normalization
In real facilities it takes a while for work-in-
progress to be moved from the place it is
created to where it is needed for further value-
addition. This time too must be taken into
account before deciding fresh allotment. Both
fixed and variable types of material movement
are considered and require separate notification
from a special console called Material
Movement Console (MMC) given to the person
responsible for material movement.
Additionally, certain WIP may require time to
set, dry, solidify, etc. We call it time to
normalize the WIP produced before further
value-addition on it can begin.
6.4 Deciding need for expediting or skipping
task allotment
Breaking a task over more than one work
centers for concurrent execution is only
advantageous if the task in question has reached
a critical stage. In our language, has sufficiently
exhausted the available leeway. Scheduler
reckons how much the current leeway available
is before taking such decisions. Likewise, if
sufficient leeway is available and if the user
desires task allotment may be skipped allowing

of 13
other urgent tasks to be handled in the
meanwhile.
Further, if sufficient time is not available to
complete a task as one has an impending NSTZ
or locked task then the scheduling engine could
either span the task, if possible, or decide to skip
allotment until later.
6.5 Deselecting inappropriate work center
At run-time work centers that were originally
thought appropriate to execute a task may
become inappropriate as they waste more than
the reported good count of inputs actually
available now. Similarly, in a multi-plant facility
if certain WIP is created in one plant and the
next value-adding work center too is available in
the same plant but not currently free then the
scheduling engine may decide to wait for it to
become free rather than send WIP to another
plant’s work center if doing so is advantageous.
6.6 Deciding to hasten-up task execution
No matter how complex a rule one may use to
anticipate task’s total duration it is still an
estimate. When situation demands one may
slightly expedite task execution to finish it faster
than expected. It is a done thing in practice and
the scheduling engine too, if necessary, does the
same, of course within user permitted limits.
6.7 Decision to re-purpose inputs
Identical inputs could be processed by different
tasks to produce something different.
Assignment of specific task inputs is rather
notional and one can, if need be, re-purpose
inputs to expedite those tasks whose other
inputs are deemed available. Human schedulers
often take such decisions and so does the
scheduling engine provided user allows (or
defines) such a swapping as possible.
6.8 Decision to freeze part or whole order
In case of any reported shortfall in WIP count for
any reason it makes sense to temporarily halt
order execution, make good the shortfall and
then resume executing order again. Humans do
take such decisions and so does the scheduling
engine. It decides to suspend order execution
while raising an alarm for human intervention to
amend order workflow.
6.9 Monitor completion is within committed
date
Generally one must keep some safety buffer
between when actually an order will be
completed and the date of delivery committed
to the customer. On each reschedule, expected
completion time for all orders are re-calculated.
However, if for some reason order completion
crosses the cut-off date an alarm is raised by the
scheduling engine.
6.10 Monitoring task execution (duration,
wastage, cost etc.)
Expected duration, cost, wastage, time for the
output from a task to become usable for
subsequent value-addition (normalization time)
and capacity the task may partake of each work
center it can be executed on, are all calculated
during job definition stage itself in the JSW.
User can define complex formulae and lookup
tables using attribute values specific to each
task to arrive at these figures. However, the
scheduling engine also captures the actual
values in each case. Doing so not only allows
one to control deviation task-wise at run-time
but enables periodic revision of estimation rules
in order to match them to reality as closely as
possible.
For example, if any task actual execution time
exceeds its estimated duration it turn black on
the live Gantt chart allowing concerned
supervisors to only focus on late tasks. Several
useful reports too can be generated highlighting
exceptions. Actual vis-à-vis estimated data can
also be used to tailor a micro-level incentive
scheme as resource capacity is translated in
time terms and thus easier to assess and
monitor.
6.11 Procurement and maintenance too are
considered tasks
We consider procurement of customer inputs
and raw material too as tasks performed by
customer interaction personnel or buyers. Any
deviation in expected arrivals of inputs has a
bearing on the overall schedule. Likewise,

of 13
maintenance activities also keep the work
centers busy and affect the schedule and thus
are treated as tasks.
6.12 Actual task execution may not always be
successful
Every allotted task may not be completed
successfully. We have the following options
available with the Operator for an allotted task.
Operator can roll back an allotted task with a
request to reassign it later. In case, Operator
has already started working on the task it could
still be re-allotted: a way of telling the
scheduling engine that it is not possible to
complete the task now though it can be
completed later by me or by someone else.
Operators’ can pause and resume working on a
task. In the worst case, Operators’ can also
declare a task as terminated meaning it is no
more possible to complete the task as inputs are
either damaged or destroyed - an error
condition requiring human intervention to make
good the shortfall. All the above impact the
schedule and are considered by the scheduling
engine.
Then there are several more activities
performed by the scheduling engine like –
 Reassessing what is completed until now
 How much more time existing tasks would
require
 The actual time, wastages and costs
(including overtime cost) incurred until now
and so on.
It is very easy to guess, a lot of thinking happens
to ensure that each allotted task can indeed be
executed on the shop floor and every
eventuality, even after task allotment, is taken
cognizance of. Technically the scheduling
engine can run autonomously with inbuilt
capability to raise an alarm for human
intervention only when situation so warrants – a
precondition for realizing a true computer
controlled manufacturing facility.
7 Vital statistics from the first successful
installation
The entire system is now mature and rigorously
tested to exacting conditions in its first full-
fledged installation at a medium sized
commercial print setup in India. It has been
working for more than 3 years now giving us the
confidence to make it available for the benefit
of the world at large.
The system is user configurable and starts by
defining the manufacturing facility in detail.
They include identifying:
7.1 Work centers
Listing of individual work centers of the factory,
classified by departments, and if a multi-plant
(location) facility, then by plants. The first
installation is a multi-plant facility. Table-2 gives
details of the work centers and their
distribution.
Table-2: First installation work center details
Number of individual work
center
419
Number of departments 47
Number of plants / locations 5
7.2 Tasks and what they produce
Tasks get executed on work centers. Tasks
produces some things recognized as
“component” and may also require some things
to add value to, again a “component”. The tasks
and the components it produces actually make
up the CT diagram. User must define what
elemental value-adding tasks can be performed
in the facility and what generic components
they produce. They are but few in type - what
changes from order-to-order is are the
attributes of generic tasks and components like,
extent to be value-added, cost, wastage,
duration, etc. Table-3 details the number of
generic tasks and components defined in the
first typical installation.

of 13
Table-3: First installation task & component
details
Number of generic tasks 27
Number of generic
components
71
Actual system performance as on 19
th
April
2013.
History: The first installation is in its fourth
successful year with the average mean time
between system failure now exceeding 6
months, which in the beginning was around 6
minutes. That shows how reliable the system
now is.
Each time a job is scheduled it is given a running
serial number. It started from ‘1’ and now reads
30900. With 706 currently active jobs, it means
30194 jobs were successfully executed by or via
the system with each job having about 70
elemental tasks on an average.
How fast it works: The scheduling Engine works
on Dell T310 Power edge server. It has 706
currently active jobs with 49466 elemental tasks
to schedule individually with all the complexity
of decision making already described. Table-4
gives an actual peek of the speed at which the
system works on this date.
Table-4: First installation Scheduling Engine load
Number of active jobs 706
Number elemental tasks to
reckon with
49466
Time to decide what to do
NOW (seconds)
4
Time to reschedule: predict
micro-level future schedule
completely (seconds)
25
Scheduling engine work at a phenomenal speed
of about 1900 tasks / second when it
reschedules, that happens once every minute
making the system live. You can guess the
decision to allot tasks now and knowing effect of
all current decisions as schedule prediction are
independent processes. Time to reschedule is
decided by the number of elemental tasks
present and varies linearly. In worst case
scenario, if time to reschedule exceeds 60
seconds the system automatically, for such
instances, chooses to skip a reschedule to align
with the next minute.
8 Conclusion
Talika PMS is in its infancy. It is just born. Not
many are even aware that such an inexpensive,
easy to use, self-configurable, off-the-shelf
product exist that holds the promise of
positioning any manufacturing facility leagues
apart from its competitors in terms of cost of
production and reliability of service offered. It is
just a matter of time before someone makes a
beginning forcing others to adopt similar
systems just to remain in business.
You can know more about Talika PMS by
visiting www.etalika.in and also download a
free full demo version for evaluation.

of 13
Exhibit–1: Console Functionality in brief
Console Function Number & Location
Job Study Wizard
(JSW)
Define and estimate all aspects of an
orders;
Simulate or schedule orders;
Monitor order progress;
Manage / Change order execution;
CRM functionality.
JSW is a multi-use console. Sales
persons, Customer Support
personnel, shop floor Managers
and Supervisors and even
customers all can have one for their
personal use.
Work Center Console
(WCC)
It is the Operators’ console. Details of
all allotted tasks flow in real-time to
these consoles for Operators’ to notify
task progress milestones.
Also gives details of all tasks already
done and those lined up for execution
later.
Valuable machine statistics and many
more helpful features.
One WCC can represent one or
several or all work center in a
facility. Users can tailor the
number of WCCs required to cover
all work centers on the shop floor.
System puts no higher limit.
Customer Interaction
Console (CIC)
Any inputs required from customers?
Track, follow-up and notify input when
they arrive in order of requirement
As many as personnel involved in
managing customer inputs.
Maintenance Console
(MTN)
Preventive Maintenance as well as
unexpected breakdowns engage work
centers and affect the schedule. One
can define preventive maintenance
schedule in advance and treat it like a
maintenance job that can be scheduled
like any other order. This console helps
define a preventive maintenance
program, schedule it and notify its
activities.
As many as required.
Material Movement
Console (MMC)
Movement and storage of work-in-
progress is a critical function in the
value-adding process and affects the
schedule. We designed a console for
the person in charge of work-in-progress
that performs all functions as required
in real-time.
Inventory
Management
Consoles (IMCs)
Orders may require raw material either
sourced from stores or purchased.
Need for material is decided and driven
by the scheduling core and thus an
entire material management system is
created around the scheduling core.
This one console takes different avatars
depending on what specific inventory
functionality is required.

of 13
Console Function Number & Location
Factory dB Manager
(FDM)
System is fully user configurable and all
this information resides in one logical
database called the factory dB.
However, user must have a means to
modify the factory dB without affecting
current working system. FDM allows
one to check-out locally a copy of the
factory dB for manipulation / change,
revalidate it and check-in the factory dB
when finalized.
Money Management
Console (MMM)
All monetary information generated by
the scheduling core is fetched
periodically by this console for financial
accounting purposes. One can then
build or dove tail this information into
any existing financial ERP system.
As many as required. Only in
concept stage.
Human Resource
Consoles (HRC)
Manpower information like past usage,
current manning information being used
and future requirements too flow from
the scheduling core. This console is
designed to cull out or control such
information or feed it into any existing
ERP system.
As many as required. Only in
concept stage.
References
[1] D. Ouelhadj, S. Petrovic - A survey of dynamic scheduling in manufacturing systems - Springer Science:
Journal Scheduling (2009) 12: 417–431 - Published online: 28 October 2008
[2] Cowling, P.; Johansson, M. - Production, Manufacturing and Logistics
Using real time information for effective dynamic scheduling - Elsevier: European Journal of Operational
Research 139 (2002) 230–244
[3] Guilherme, E.V.; Herrmann, J.W.; Lin, E. - Rescheduling Manufacturing Systems: A framework of
strategies, policies and methods - Journal of scheduling, Kluwer Academic Publishers, Netherlands
[4] Velaga P., Ph.D. (Scheduling) President, Optisol, 3910 Stony Creek Ln, College Station, Texas 77845 -
Advantages & Difficulties with Drag-and-Drop Operations – Web page link: http://www.optisol.biz/Drag-
and-Drop.htm
[5] Zhang L., Li, X., Gao, L., Yang, Y., Jiang , P. - Predictive/reactive scheduling with uncertain disruptions -
proceedings of the 41st international Conference on Computers & Industrial Engineering P 260-265

An Innovative Real Time Production Management System

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (7)

Similar a An Innovative Real Time Production Management System

Similar a An Innovative Real Time Production Management System (20)

Último

Último (20)

An Innovative Real Time Production Management System