APPLICATION WHITE PAPER: Multi-site, Multi-user Collaborative Scheduling Using Preactor

Transcription

1 APPLICATION WHITE PAPER: Multi-site, Multi-user Collaborative Scheduling Using Preactor GENERAL Gregory Quinn Vice President North America, Preactor International Ltd President, Quinn & Associates Inc As companies consider scheduling solutions they are often faced with a decision between single site systems that force schedule models that are so large in data content that only simple scheduling rules are effective as a near-real time decision support tool, or scheduling systems that provide multi-user scheduling systems that are fixed, with no real extensions to modeling capability other than the option for user-defined data fields. Preactor scheduling software provides many advantages to companies looking to automate their scheduling without suffering from the limitations in performance or complexity. Since its introduction in 1993, Preactor planning and scheduling software has been deployed in thousands of companies around the world (see Preactor has been deployed in many multi-site and multi-user configurations - multiple factories within a division or corporation (see Preactor white paper Preactor Planning and Scheduling Software for Enterprise Application ) as well as with multiple users within a factory. These capabilities evolved over time and with the introduction of the Preactor Communications Object (PCO) in version 9, the collaborative scheduling for end users gained greater flexibility, reflecting the evolution of the software to meet changing needs in the marketplace with more complex requirements driven by enhanced supply chain execution with enriched end user experience. Collaborative scheduling is a Preactor architecture where multiple schedulers can contribute directly to the overall schedule based on their individual areas of responsibility. The focus of this application note is to discuss the license topology options and features available to the Preactor end users within the collaborative environment. DEFINITIONS Certain terminology will be introduced in this paper to explain roles of the licenses that appear in various architectures. Two essential terms are: Master Scheduler: The general use of this term refers to the ability to have unlimited administrative control over the structure of the scheduling model and posting of the results of the Preactor application. In collaborative scheduling an end user with a master scheduler role also has the ability to enforce global scheduling decisions upon other users in the system.

2 Co-Scheduler: A Co-Scheduler has ownership of a subset of resources or customers (or both) and contributes adjustments of those jobs to the other co-schedulers in the system. TOPOLOGIES There are three basic topologies in use for collaborative scheduling: 1) Peer-to-Peer In this architecture no one scheduler exercises complete control over the entire schedule. Each Co- Scheduler adds their adjustment to the schedule as those changes affect their resources and customers. Divergent or problematic schedules are resolved by consensus between the co-schedulers. 2) Master Scheduler with one or more Co-Schedulers This topology will have one Master Scheduler seat with overriding control of the updates from the Co- Schedulers in the system. This centralized control permits the updates and changes from the Co- Schedulers to adjust the schedule, but the Master Scheduler can enforce a global adjustment to all schedulers in the system. 3) Multiple Master Schedulers with one or more Co-Schedulers This is the most complex combination of roles within the Preactor collaborative environment. While topology #1 would be most often a single tier system and topology #2 would be a two-tier system, this topology would be an n-tier system for large scale multi-plant and multi-user scheduling systems. In the discussions that follow, scenarios will be focused on the more common deployment model (1) illustrated by a two scheduler application (schedulers A and B). All concepts presented herein can be extended to any of the topologies described above. BASIC ELEMENTS FOR COLLABORATIVE SCHEDULING Preactor offers a number of configuration elements that are important to allow schedulers to collaborate effectively. These are: - Scheduler Types: The ability to define the relationship between schedulers working within the system - Assignment to Schedulers: The ability to make selective assignment of Resources to a scheduler to manage work centers or departments and Customers in situations where schedulers work with account responsibility - Locking: Reserves the exclusive use at resource, customer, order, or operation level in order to model the production management practices for a specific environment - Activity Messages: A communications system to send alerts to schedulers working on the schedule

3 - Scheduler Repair: A framework to create policies to govern consolidation of changes and updates to the overall schedule SCHEDULER TYPES There are two types within the collaborative environment: Master Scheduler and Co-Scheduler. As shown in the Preactor screens, the main screens indicate the activation (or lack) of the Master Scheduler privileges. Scheduler A has the ability to enforce all of the changes in his or her schedule to all of the schedulers within the network, effectively replacing the co-scheduler schedules with A s schedule. Scheduler B can only affect A s schedule through dragging and dropping operations, locking operations or resources, or through a local schedule repair. B cannot replace A s schedule in its entirety. ASSIGNMENT TO SCHEDULERS Each scheduler is assigned certain resources and customers. These controls are set in the Customer Database and Resource Database, as shown below:

4 It is worth noting that ownership can be unspecified. In those cases then any scheduler can make changes to jobs as it applies to those resources or customers. Customer assignment also means that the scheduler owns all orders for the customer. In jobs where product has been aggregated to a batch for simultaneous processing, then the Customer assignment does not apply. It is also possible to assign Product to a scheduler; however this is in place of Customer assignment. Feedback has indicated that responsibility is either with Customer or Product, but not both. LOCKING A scheduler can enforce locking or unlocking at four levels: Resource, Customer, Order, and Operation. Locking reserves exclusive use for the Co-Scheduler subject to the initial assignment in the Resource and Customer databases.

5 Conversely unlocking permits other schedulers to access those elements for purposes of making adjustments when a Co-Scheduler s order may affect a resource belonging to another Co-Scheduler. Resource locking is indicated within the order information: Furthermore, if a Co-Scheduler attempts to lock a resource, order, or operation assigned to another coscheduler, a Preactor warning message appears: The order has priority over resource in the event of a scheduling conflict, so an order for a customer may alter the sequence of jobs on a resource even though the resource may be assigned to a different Co-Scheduler.

6 ACTIVITY MESSAGES Within the collaborative system, as a Co-Scheduler makes changes, those changes appear in all other Co-Schedulers and Master Scheduler (if used in the topology) screens. For example, operation 10 of Order A is moved two hours later in the scheduler, the Gantt bar representing Operation 10 will reappear in all the other schedules with the two hour delay when the Co-Scheduler completes the drag of Operation 10. Preactor also provides for messaging through the PCO to all Co-Schedulers in the systems, such as: The first message indicates an operation 20 of Order A007 has either been moved to the Lathe resource or the job has been moved forward or backward in the schedule timeline. The second message shows that co-scheduler B has locked the Subcontractor Heat Treatment resource. SCHEDULE REPAIR In the discussion so far, individual job movement or resource changes has been described. Unless otherwise disabled, each co-scheduler can affect a Scheduler Repair, a standard feature in Preactor. A Master Scheduler can enforce his or her repaired schedule upon all users. When a Co-Scheduler without Master Scheduler privileges repairs his or her local schedule, those repairs are broadcast to other users.

7 However, the information only relates to elements in the schedule owned by the Co-Scheduler. For example, scheduler B repairs his or her schedule. Messages via PCO go out to scheduler A and any others on the system. Scheduler A can elect to accept those changes. If not, then scheduler A will be operating with a schedule that differs from that schedule used by scheduler B. In time the differences may become significant, and schedulers A and B will need to agree upon a reconciliation of the two schedules. CONCLUSION This application note serves to introduce the idea of collaborative scheduling using Preactor. Many of the features shown are configurable, and like the basic topologies, can be altered to fit the specific needs of the client s current or future practices. Some customers are inclined towards fewer scheduling models with greater complexity whereas others show preference to many albeit simpler models. Preactor meets the demands of both it is simply a matter of how many scheduling models are to be deployed. The enhanced collaboration of schedulers has far reaching implications for the enterprise: - A single application can standardize the shop floor and extend well into the supply chain execution model for a diversified corporation - Reduce uncertainty, conflict, error, and misunderstanding in coordinating tasks across the organization - Knowledge rises from the individual level to the group level minimizing risk of single point of failure in complex scheduling while improving dynamic decision making - Schedulers communicate with common purpose This flexibility offers an overall return on investment that can be measured in months or weeks vice years continuing Preactor s commitment to the lowest total cost of ownership without sacrificing capability.