Liquid Pipeline scheduling varies from being simple to very complex as the size of the network grows and a point will be reached where an initially deployed legacy or home-made solution may no longer support the current requirements. This problem is further exacerbated by an ageing work force and lack of knowledge transfer from one generation of schedulers to the next.
It is often the case that when pipelines were constructed initially, the process and systems were lacking in complexity and functionality leaving most matters being dealt with by using standard rule of thumb or set practices. But with increasingly complex network growth, numbers of products being transported, stringent interface management and increased focus on optimization, the legacy systems and spreadsheets may no longer support the increasing demands.
Migrating from a legacy application to a standard industry bench-marked solution helps the pipeline company to reduce dependency on individuals and makes scheduling a more process driven approach, enabling greater control over the scheduling process. A modern product-based solution also helps in identifying beneficial practices that were previously unapproachable such as optimization of the costs incurred while running combinations of pumps, or optimized usage of drag reduction agents, or a combination of both. Besides offering greater visibility of the schedule for a pre-defined period across various hierarchical levels, a modern scheduling tool will also have interfaces to enterprise applications such as SAP and SCADA thereby facilitating the improvement in the fidelity of the scheduling by utilizing the most recent data for e.g., tank levels or line fill data.
This paper pulls together experiences of implementations of scheduling solutions and their varying level of user acceptance. The paper highlights common reasons that hinder a scheduler from fully utilizing an available system. The paper identifies the most common amongst these (like non-availability of external interfaces that leads to a lot of data entry) which when provided may enable a higher user level acceptance of an implementation.
The paper also tries to define the optimal time when a pipeline company with a medium to complex pipeline network should consider migrating from a legacy application to a standard, or a tailor made, solution by considering the level of maturity of systems and the processes that exist at various levels within the organization. Recognizing that the pipeline system will continue to evolve indicates that the tolls supporting the pipeline will also continue to evolve and therefore the paper considers what steps should be in place for scaling up the solution from time to time. Finally, the paper discusses what is required to achieve the all-important user buy-in and acceptance of the system.
