decision support systemskianaco.net/download/articles/2014/10.1016-j.dss.2014.09.003-decision... ·...

Decision Support Systems xxx (2014) xxx–xxx

DECSUP-12530; No of Pages 15

Contents lists available at ScienceDirect

Decision Support Systems

j ourna l homepage: www.e lsev ie r .com/ locate /dss

Decision support in hierarchical planning systems: The case of procurement planningin oil refining industries

Kasper Bislev Kallestrup a, Lasse Hadberg Lynge a, Renzo Akkerman b,⁎, Thordis Anna Oddsdottir a

a Department of Management Engineering, Technical University of Denmark, Produktionstorvet 424, 2800 Kgs. Lyngby, Copenhagen, Denmarkb TUM School of Management, Technische Universität München, Arcisstr. 21, 80333 Munich, Germany

⁎ Corresponding author.E-mail address: [email protected] (R. Akkerma

http://dx.doi.org/10.1016/j.dss.2014.09.0030167-9236/© 2014 Elsevier B.V. All rights reserved.

Please cite this article as: K.B. Kallestrup, et alindustries, Decision Support Systems (2014)

a b s t r a c t
a r t i c l e i n f o
Article history:Received 3 October 2013Received in revised form 11 August 2014Accepted 13 September 2014Available online xxxx

Keywords:Advanced planning systemsHierarchical planningCrude oil operationsProcurement planning

In this paper, we discuss the development of decision support systems for hierarchically structured planningapproaches, such as commercially available advanced planning systems. We develop a framework to showhow such a decision support system can be designed with the existing organization inmind, and how a decisionprocess and corresponding software can be developed from this basis. Building on well-known hierarchicalplanning concepts,we include the typical anticipationmechanisms used in such systems to be able to decomposeplanning problems, both from the perspective of the planning problem and from the perspective of the organiza-tional aspects involved. To exemplify and develop our framework, we use a case study of crude oil procurementplanning in the refining industry. The results of the case study indicate an improved organizational embedding ofthe DSS, leading to significant savings in terms of planning efforts and procurement costs. In general, our frame-work aims to support the continuous improvement of advanced planning systems, increasing planning quality incomplex supply chain settings.

© 2014 Elsevier B.V. All rights reserved.

1. Introduction

Managing supply chains is a complex task and is often done withhierarchically structured advanced planning systems (APSs) [47]. Dueto the complexity and uncertainty in supply chains, it is normally notpossible or desirable to create fully automated decision systems thatrapidly identify and execute optimal decisions. Even if it were, it is likelythat managers would not trust such a system blindly, due to the veryhigh potential costs of erroneous decisions. Instead, managers turn todecision support systems (DSSs), which support planning processes asgood as possible.

A DSS involves a human–computer interaction and the software partusually provides a range of information that managers use to decide onan action. Literature on DSSs in relation to APSs focuses primarily onmodeling or data structure aspects. As documented by Zoryk-Schallaet al. [51], focusing on modeling aspects early in the development ofDSSs for APSs, without properly defining the planning process and itscharacteristics, can lead to significant implementation problems. Thiscalls for research on the development process of APSs, especially relatedto the planning process complexities, information requirements, aswellas the organizational embedding [20].

The planning processes covered in APSs normally span different func-tional domains (e.g. production, distribution, sales) and include decisionproblems with different time horizons and granularity (from strategic to

n).

., Decision support in hierarch, http://dx.doi.org/10.1016/j.d

operational). This range of planning processes is often also reflected in or-ganizational structures, which increases the need for coordination be-tween the different processes. It is exactly this coordination in thehierarchical structure and the related information flows that are key fac-tors in the development and implementation of APSs [48], and often thereason to implement an APS in the first place [20]. Even though there isan increasing body of work on APSs and other hierarchical planning sys-tems, how to develop additional decision support in a structuredway re-mains a challenge, especially when taking into account the existingplanning infrastructure and its organizational embedding.

In this paper, we address this problem by developing a framework tosupport DSS design, considering organizational aspects and processdesign early in the development process. More specifically, we contributeto the decision support literature by answering (i) how a DSS for an APScan be designed with the existing organization in mind?, (ii) how a deci-sion process can be developed from this basis? and (iii) how theinformation obtained from the first two steps eases and directs thedevelopment of the enabling software? As we base our work on well-known hierarchical planning concepts, we also contribute by providinginsights on the anticipation mechanisms used in such systems to beable to decomposeplanning problems. Sinceweproposemethods for cre-ating DSSs in commonly used APS settings, we also ensure professionalrelevance [4]. Throughout the paper, we will use a case study of procure-ment planning in the refining industry, an industrywhere advanced plan-ning systems have traditionally seen extensive use [14,40]. However, theprocurement planning problem has been an underdeveloped aspectwithinAPSs [33], and previous research has often notmanaged to capture

ical planning systems: The case of procurement planning in oil refiningss.2014.09.003

http://dx.doi.org/10.1016/j.dss.2014.09.003

mailto:[email protected]


http://www.sciencedirect.com/science/journal/01679236

www.elsevier.com/locate/dss


2 K.B. Kallestrup et al. / Decision Support Systems xxx (2014) xxx–xxx

the decision problem properly [35], and it is therefore a good environ-ment for the discussion of the DSS development process.

In the following section, we first discuss the main literature streamsrelated to our study. Based on this, Section 3 develops an initial develop-ment framework for model-based DSSs for APSs. In Section 4, we thenoutline the general structure of procurement planning in the refineryindustry, followed by the application of our development frameworkto create a DSS in Section 5. In Section 6, we further refine our frame-work based on the case results, followed by conclusions and furtherresearch directions in Section 7.

2. Related literature

2.1. Decision support systems

Creating DSSs is away for organizations to improve the efficiency andeffectiveness of their decision processes. Power [38] argues that how toimprove a decision process depends on how ill-structured the decisionproblem is. Ill-structured problems are defined by what they are not,namely well-structured problems. A well-structured problem is a prob-lem that is routinely carried through, where the solution can be checkedand where the end goal can be met in a reasonable amount of time [46].According to Power [38], problems that arewell-structured can normallybe automated in a decision system, while ill-structured problems needspecial decision studies. Problems that lie in-between these extremes(semi-ill-structured problems) can normally benefit from a DSS.

Conceptually, a DSS is a formalization of the knowledge and experi-ence held by employees involved in the process, structured in a waythat enhances the decision maker's ability to choose the best solution toa complex problem [25]. According to Holsapple and Whinston [16], aDSS is a human–computer interaction, where the computer consists offour elements, illustrated in Fig. 1.

A DSSmay use a database analysis system to createmetadata that cangive new insights for managers or provide a mathematical model of theproblem domain that greatly reduces a problem's solution domain.Early descriptions of management information systems used for decisionsupport focused on the analysis of the decision system and condensationof data [1] as a means to ensure that software systems would provideonly information that was relevant to the decision maker. Courbonet al. [8] described the design of such systems as evolutionary, a conceptthatwas expanded and popularized by Keen [23]. Keen argued that a DSScan only exist if it is a product of an adaptive process between the systemand the user, where the system encourages the user to take new ap-proaches, which in turn lead the user to request more features from thesystem. Both Keen and Courbon et al. focused on the software engineer-ing aspects of DSSs, assuming that a good decision process would evolvenaturally. Other authors, including Blanning [6] and Linger and Burstein[31] used the analysis of the decision making process to identify whatfunctions a DSS should have. Blanning also mapped modules of the DSSto the different departments in an organization.

Gachet and Haettenschwiler [12] reviewed nine different DSS devel-opment methodologies and advocated for those that combine systemengineering aspects and decision making process aspects. These inte-grated approaches include Keen and Scott-Morton's [22] widely

Fig. 1. Structure of DSSs according to Holsapple and Whinston [16].

Please cite this article as: K.B. Kallestrup, et al., Decision support in hierarchindustries, Decision Support Systems (2014), http://dx.doi.org/10.1016/j.d

accepted “Design Cycle” and Saxena's [41] “Decision Support Engineer-ing”, both of which place the decision analysis task or process develop-ment task as an antecedent of the software development task. Saxena'sapproach also includes a range of interactions that challenge thesequential structure, in order to allow for the evolutionary characteris-tics of DSSs.

2.2. Hierarchical planning structures

Hierarchical planning is important if one seeks to optimize systemswhere scheduling is critical and non-trivial tactical decisions, such asprocurement and network planning, have a larger horizon than it ispossible to optimize scheduling problems for. Planners usually solvethis problem by splitting the system into at least two planning levels,an aggregate level and a detailed level. One of the earliest approachesto structure a planning system hierarchically was presented by Haxand Meal [15]. They proposed a hierarchical system that can “makedecisions in sequence, with each set of decisions at an aggregate levelproviding constraints within which more detailed decisions must bemade”. Bitran et al. [5] also argued that hierarchical planningmodels can replace difficult-to-solve stochastic planning models whendemand for individual products is stochastic but deterministic foraggregated product families. A robust aggregate plan is defined byLasserre and Mercé [29] as a plan for which a feasible disaggregationpolicy can be formulated. Gfrerer and Zäpfel [13] subsequentlydiscussed how robust aggregate plans can be enforced through top-down coordination.

A conceptual framework for describing hierarchical structures, likethose in hierarchical planning systems, was proposed by Schneeweiss[42]. In a hierarchical structure, there will be a top level (aggregatelevel) and a base level (detailed level). The top level can instruct thebase level and the base level can react to these instructions. In top-down hierarchical structures like APSs, the base level cannot present areaction before the decision is implemented in the object system(production system), but instead, the top level anticipates how thebase level will react. The anticipation in the top level can then beupdated/refined based on ex-post feedback from the object system. Insubsequent work, Schneeweiss [43] distinguishes three categories ofanticipation: (i) considering characteristics of the base level directly(perfect anticipation), (ii) considering approximations of base-levelcharacteristics (approximate anticipation), or (iii) considering part ofthe base-level characteristics (implicit anticipations). For non-perfectanticipation, which is normally the case in practice, the reaction fromthe object system can be quite different from the anticipations.Decision-makers can reduce the problem by increasing the quality ofthe anticipation, which is often a key aspect in the design and operationof hierarchical planning systems.

Hierarchical models can in some simple cases be autonomous, but inpractice, a hierarchical planning system takes the form of an APS thatcombines autonomous decision modules with DSS modules [47]. Theuse of DSS modules is necessitated by the complexity of supply chainsand, to some extent, the capacity of modern algorithms and computers.APS modules are either technically integrated or integrated throughorganizational processes. Most of the DSSs in APSs are model-basedoptimization tools (using Alter's [2] taxonomy), simply because plan-ning and scheduling have traditionally been areas that heavily utilizeoperations research methodology.

Researchers report that APSs are widely used in the industry, but ithas been argued that this is not reflected in DSS research [32]. As aconsequence, DSS literature does not always describe the task ofpositioning a DSS, which determines the users, their objective andtheir organization. In a single-level planning process, this may bestraightforward but for APSs, where multiple planning levels exist andmany organizational units are involved, positioning a DSS is notstraightforward.



3K.B. Kallestrup et al. / Decision Support Systems xxx (2014) xxx–xxx

2.3. Crude oil procurement planning

In this paper, we consider the case study of crude oil procurementplanning for refining industries. Fig. 2 shows a typical APS for petroleumsupply chains. Positioning a DSS for procurement planning within thisstructure is a non-trivial task. Related planning tasks include the crudesupply scheduling level, the production and master planning level,and the strategic planning level. This positioning determines whatinformation, generated in one of the other functional columns (produc-tion, distribution, sales) or in the market, is available to the DSS, andwhat information the DSS generates for the system.

The problem processing system in a DSS normally builds on formal-ized models of the problem domain. Decision support models forprocurement planning have not received much attention in the quanti-tative operations management literature. Most work on procurementconcerns the qualitative evaluation of different suppliers [7,10], some-times followed by a quantitativemodel to support the selection process[19]. This is then typically the basis for contract negotiation and theactual ordering processes that are often based on classical inventorycontrol. As an alternative to these supplier-focused approaches, wealso see procurement of raw material on spot markets [17], often usedin dual sourcing strategies as a supplement to a supplier base to beable to deal with demand uncertainty [18]. Approaches that try tocapture the decision of procuring raw materials from different sources,including discrete short-term opportunities for sourcing, are howeverless common. Specific work on the procurement of crude oils is alsorather limited. As is the case for a lot of natural resources, quality varia-tions in the rawmaterial often lead to blending problems, complicatingprocurement decisions. Kingsman [24] already identified this problem,and it has often been included in production scheduling (especially inthe refining industry), but it has not seen much attention in decisionsupport for procurement planning. Some previous work does howeverexist. Julka et al. [21] and Pitty et al. [37] investigate different forms ofsimulation-based decision support systems for managing supply chainsin the petroleum industry. Julka et al. [21] propose an agent-basedsystem that models third-party logistics providers, the procurementdepartment and the internal logistics department as separate entities.Between these, offers and deals aremade automatically based on a static

Fig. 2. An ‘ideal’ downstream petroleuAdapted from Roitsch and Meyr [40].


sequence, defining the procurement process. Pitty et al. [37] describe asimilar dynamic simulation system. It models suppliers, the procure-ment process, crude operations, product operations, and customers. Ina subsequent paper [26], they propose that the system can be connectedto a search heuristic and, through many subsequent simulations,optimize against an objective.

None of them, however, consider the blending of crude oils, but relyon a strict pre-qualification, which is too restrictive in a lot of practicalsettings. Other researchers approach procurement from a risk man-agement perspective and use stochastic programming or linear pro-gramming models to identify the optimum product slates for arefinery [27,37]. They do, however, not consider a limited availabilityof specific procurement opportunities, but rather assume the utopiansituation that crude oil procurements are profitably available so themix of crude oils at the refinery can be kept constant during theplanning horizon.

To address this lack of approaches that are able to deal with realisticsituations, Oddsdottir et al. [35] recently developed a solution approachto solve a non-linear procurement planning problem that includesmostrelevant practical problem characteristics. The formulation is a mixed-integer non-linear programming (MINLP) model that is solved using atwo-stage solution approach involving a linearized version of the origi-nal MINLPmodel, and a reduced MINLPmodel that represents the non-linear problem with all procurement decisions fixed. In our case study,the problem processing system of our DSS will be based on this work.

3. Developing model-based DSSs for APSs

DSS design methodologies (e.g. [16,25,38]) tend to assume that thecomputer in a DSS will automatically have a user. This assumptionfails whenever a DSS is to be used in an APS, where many actors areinvolved and many decision processes are interconnected. In hierarchi-cally structured systems, we need explicit focus on the organization.Some authors that develop decision systems for hierarchical systems,do consider the organization of work as they define planning levels[11,36,50], but they concentrate on the issue of defining the correctmathematical models, and aggregation/disaggregation rules, so theyonly consider the organization within the software aspect of a DSS.

m supply chain planning system.




They fail to describe how the systemwill interface with the real organi-zation and its work systems. This focus will, as was also pointed out byAlter [3], lead designers to create DSSs that have little or no impact onreality.

In our view, users for a DSS only come into existence once thedesigner defines how the DSS is positioned within the hierarchicalstructure of the APS and the organization. To ensure that theuser(s) will be able to use the DSS effectively, the designermust furtherdesign the interaction between human and computer, a new decisionprocess that utilizes DSS software. When developing a DSS for an APS,there are consequently three aspects to consider: Organization, process,and software. The supersystem of these three will always be the organi-zation, as the organization defines the purpose. Subsequently, businessprocesses structure elements and their relations to support thispurpose. Finally, software is an element that can enable these processes.

These antecedence relationships imply a certain sequence thatshould be reflected in DSS development. The relationship betweenprocess and software is recognized by most integrated DSS develop-ment methodologies, as they develop the process before the software[22,41]. The relationship between organization and process has howev-er not received much attention.

If developers start by modeling the software/planning model, theywill likely start by prototyping a model for a simplified problem andthen expand on this until the requirements of the project are met. Thesimple problem might be found at the most aggregated level, whiletheDSS naturallyfitswith the least aggregated level. The data structuresused initially will then be dramatically different fromwhat is necessaryin the end.

Disregarding the organization aspect will consequently lead tohigher project costs and longer delivery times, as also documented by[51]. Fig. 3 illustrates our initial framework for the continuous processof developing DSSs for APSs. When it becomes obvious that a decisionprocess in an APS is flawed and that it can be improved by a DSS (theroot-cause is a semi-ill-structured problem), designers should start byinvestigating the inadequacy. This provides the requirements for a DSSdevelopment process. The development process should consider allthree aspects of the future DSS in accordance with the logical sequencebetween them.

The primary contribution of our approach to DSS development isthat we extend our DSS model to explicitly include the organization inan integrated framework that also considers the decision makingsupport (process) and the system engineering (software) aspects.

Fig. 3. Initial conceptual framework on the development of DSSs for APS.


In the case study presented in Section 5, we apply this conceptualframework. From an analysis of the decision inadequacy, we start thedevelopment process by positioning the DSSwithin the existing organi-zation. We then design the business process aspects of the DSS. Thishelps in identifying the users of the system and their interactions withthe system. Once the target process is determined, we use the informa-tion gathered from the first two steps to develop the elements of thesoftware.We use the case study as an illustrative example of a companywith a hierarchical planning structure, embedded in an organizationwith various functional areas involved in one or more planning tasks.In developing the detailed planning model, and the required anticipa-tion mechanisms, we needed to consider some more industry-specificaspects, such as the complex connections between the availability ofraw materials and the feasibility of production plans. This aspect ishowever common for the process industry, as argued by Crama et al.[9], and might therefore not only be case-specific. Furthermore, for thesake of generalizability of the results, the important aspect is thatthere is some kind of anticipation mechanism that links the planningproblem at hand to another planning problem it influences. Here, theanticipation of how the procured materials are actually used on themore detailed production planning level is a typical example of antici-pation in a supply chain context.

Before we present the case study, we briefly introduce the oilrefining industry and the concepts of crude oil procurement planning.After the case study we revisit our framework in Section 6 and refineits details, based on the experiences from the case study, to developthe final version of our DSS development methodology, applicable tohierarchically structured APSs.

4. Crude oil procurement planning

At the most general level, oil refineries distil a flow of many hydro-carbons, crude oil, intomany flows of single or few hydrocarbons, prod-uct cracks. This is done in the refinery's Crude Distillation Units (CDUs).Product cracks can then be further refined to useable petrochemicalproducts, which are used by airline companies, everyday motorists,road surfacing companies, and as input to other petrochemical indus-tries. Crudes differ in hydrocarbon composition and in amount of non-hydrocarbon contents. They are often categorized according to sulfurcontents (sweet and sour crudes), density (condensates, light, andheavy crudes), and acidity (indicated by the total acid number, TAN).Relevant data on crude contents and characteristics are collectivelycalled crude assay data. The heterogeneous nature of crudes leads touneven demand and relative differences in crude prices.

A critical determinant for refining profits is the refinery's ability toprocure crudes that can be refined into end products at the highestmargin, in the largest amounts. Selecting crude procurement opportuni-ties in a way that optimizes refinery profitability is the core element ofcrude oil procurement planning. The object system, which plannersseek to control, is the front-end of a refinery, the crude operationssystem, illustrated in Fig. 4. The external constraints on the system areprimarily the market and the end-product operations that lie after theCDU. Planners would ideally consider the refining system as one entity,but complexity forces them to split the systems into crude operationsand refining operations. The end-product operations are traditionallyoptimized with approximate linear programmingmodels, and the solu-tions to these models pull the crude oil operations planning process viaCDU feed requirements on volumetric flow rates and the requiredquality of crude mix (sulfur, density, TAN, etc.).

Once production plans and CDU requirements are established,planners choose crude procurements that can be imported and blendedto adhere to these CDU feed constraints. But the product of the planningprocess has to comprise of more than an import plan. Schedules for thespecific crude flow are equally important, due to the fact that crudeimports are blended in storage tanks and CDUs are fed by multiplestorage tanks simultaneously.



Fig. 4. The object system of the crude oil procurement planning system.


The crude procurement planning process is naturally only onecomponent of the total supply planning system. Fig. 5 details the supplycolumn in hierarchically structured APSs that is typical for refining busi-nesses. The figure is based on a variety of publications related to petro-leum supply chains [28,34,40,45] as well as the authors' experience. Itshows information on managerial responsibilities, levels of planning,available information and time horizons. Most importantly, it also

Fig. 5. A generic hierarchically structured planning process for


depicts the interdependencies between the different planning levels.For example, when the long-term planning department plans mainte-nance for one of the CDUs, they do not only affect the object system,but also impose some capacity limitations on the mid-term planningprocess (a top-down instruction). The long-term planning coulde.g. anticipate that capacity utilization will be low for the next months.If this anticipation turns out to be wrong, it will naturally affect the

supply planning in the downstream petroleum industry.




performance of the object system and a key concern in a hierarchicalplanning process is thus the quality of the top level's anticipation.

Procurement planning is a process that spans multiple planninglevels and thus in many cases multiple departments. Fig. 6 shows thetypical process of creating an import plan. The specific sequence anddepartmental responsibilities will differ for different companies, butthe general structure corresponds to the literature [21,37,40]. Theprocurement process consists of several parallel processes. The long-term planning department (usually split into logistics department,procurement department, crude assay department, etc.) continuouslyworks to improve the rawmaterial supply by pre-qualifying new crudesfor their refineries and update crude assay data. They are also responsi-ble for forecasting end-product prices and estimate what margin can beachieved from refining the pre-qualified crudes, usually referred to ascrude refined netbacks or refining margins [21,37]. To do this theyneed the trading department to identify or estimate crude procurementavailability and prices. They also need the planning department of theindividual refineries to estimate what their crude stock slate will be atthe start of the planning horizon and their production forecasts. Oncethis data is collected, and netbacks have been defined, traders begin tolook for specific procurement opportunities in the market.

The mid-term planners then try to select crudes to form an importplan that will be feasible with respect to the CDU feed requirementscalculatedwithin the production column of the APS. This is a schedulingtask that is mathematically extremely difficult. If the ratio betweeninventory capacity and production capacity is low, the scheduling

Fig. 6. Elements of the crude


department will need to be included in the process to try to forecastwhat the crude stock slatewill be at a specific point-in-time, to estimateif a given procurement can feasibly be added to the stock slate, at thattime, without causing an infeasible CDU feed.

Going back to the problem classifications presented in Section 2,crude oil procurement planning can clearly be classified as a semi-ill-structured problem, as some aspects, such as selecting the most prom-ising crudes, are very difficult, while other aspects, such as evaluatingwhether a solution is technically feasible, are relatively straightforward.It therefore follows that the procurement process could benefit from aDSS.

5. Case study: development of a DSS

For a period of one year, we have beenworkingwith Statoil to devel-op a DSS for their procurement process. Earlier attempts with acommercial APS providerwere unsuccessful, as it was aiming for perfectanticipation, which turned out to be impossible. We will use this DSSdevelopment experience to illustrate the framework outlined in thispaper, and exemplify the consequences of considering the organization-al, process and software aspects of DSS to an equal degree. To developeach of the DSS aspects, we used interviews and observations to laythe basis for the process analysis and establishment of our understand-ing of the existing organization.

Statoil's procurement process is organized with a central refineryoptimization department in Stavanger, Norway and separate planning

oil procurement process.




departments at each of their facilities. In this study, we include one ofthese facilities: the refinery in Kalundborg, Denmark. The procurementprocess at Statoil is similar to the generic case described in the previoussection. The Stavanger-based employees in the Planning & Economicsdepartment calculate netbacks for each crude and facility. In collabora-tion with the Kalundborg-based employees of the Planning & Econom-ics department, they then try to select between the procurementopportunities identified by the Trading department. The Tradingdepartment has offices in Stavanger, London, Stamford (Connecticut),and Singapore. For the Kalundborg refinery, the crude oil supply ismainly handled by the Stavanger and London offices. Table 1 showshow the responsibilities concerning different planning levels at Statoilcompare to the generic case. The time horizons and information flowsare similar to the generic case.

As in the generic case, the task “Select among procurement opportu-nities” is the most challenging. The task is performed using a (manual)heuristic procedure, where crudes on the netbacks list are consideredin a prioritized manner, starting with the highest margin crudes. TheKalundborg planners and the crude oil Scheduling department atKalundborg manually fit possible crudes into the import plan andcrude flow charts tomeet the production plans for the planning horizon.The planning horizon is typically 2–3 months and flows are describedper day. If a procurement opportunity vanishes from the market,planners will have to reschedule. They often discover that the crudearrival date will ideally have to be moved slightly in time. This is thenreported to the traders, who subsequently investigate the options inthe market. They perhaps find a solution that almost fits the wishes ofthe planners and report this back to Kalundborg, where planners thenreschedule to evaluate feasibility. This iterative process continues untilfeasibility seems reasonable, and the traders can close the procurementdeal. This whole process has a long lead time (up to 14 days), and istime-consuming, due to a number of reasons:

• Manually creating crude flow schedules is extremely complex due toits combinatorial nature.

• Infeasible plans can be extremely costly once the consequences ofdecisions materialize and many scenarios with slight alterations aretherefore considered to ensure the robustness of the decisions.

• Planners and schedulers at Kalundborg work in different hours thanthe traders and the crude oil market, which means that otherwisequick confirmations from planners are sometimes postponed untilthe next morning.

This slow and iterative process can result in the loss of profitablecontracts or engagement in non-profitable contracts, when traders, inan effort to secure a good deal, sometimes have to buy before theyhave a final confirmation.

Another problemwith the process is the conflicting objectives of theTrading department, and the Planning & Economics and Schedulingdepartments. Traders are concerned with maximizing the margin,while planners and schedulers are more concerned with maximizingthe profit. To avoid situations where operators are forced to reducefacility throughput, because of problematic feedstock, planners oftenreject crudes that they are unfamiliar with. These are typically thecheap crudes with problematic qualities. They are referred to as “exotic

Table 1Comparison between generic planning systems and system at Statoil.

Planning level Responsibility

The generic planning system Statoil

Long-term Long-term planningdepartment

Planning & Economics (NO)Trading department (NO/UK)Crude Risk Assessment Team (DK)

Mid-term Planning department Planning & Economics (DK)Trading department (NO/UK)

Short-term Scheduling department Scheduling department (DK)


crudes”, and often represent significant refining margins if they can beintegrated in the procurement plan.

Comparing the organization at Statoil with the generic planningorganization, a main characteristic is that the mid-term and long-termplanning levels are geographically distributed between Norway,Denmark and the UK, as well as spread out over five departments:Planning & Economics (2 locations), Trading, Crude Risk AssessmentTeam, and Scheduling.

In summary, Table 2 lists the key issues and requirements for thenew DSS. These were then represented by a series of metrics, forwhich the current performancewasmeasured or estimated and quanti-tative targets were established. The key metrics are the refining profit,the resources spent on procurement planning, and the time requiredto create a plan.

5.1. The organization

All of the problems found at Statoil are directly (problems 1, 3, 4) orindirectly (problems 2, 5) related to the selection process “Select amongprocurement opportunities”. This is possibly due to the fact that this is ascheduling task, which is asmentioned extremely hard to solve to feasi-bility. Problem number 4 also specified the process “check feasibility ofimport plan” to be problematic. There are two ways of dealing with atroublesome task, you can either redefine the process to eliminate thetask, or you mitigate the problem related to the task.

5.1.1. Eliminate target tasksTo eliminate the task, we need to remove the object system's sensi-

tivity to the choice of crudes. Excluding non-procurement relatedoptions such as inventory expansion and facility upgrading (both strate-gic level decision), the onlyway to do this is by beingmore intelligent inthe pre-qualification of crudes. A DSS could be positioned at the long-term planning, focusing on the evaluation of which crudes are feasiblefor all possible blend ratios with the other pre-qualified crudes. Thiswould potentially increase the efficiency of the procurement process,as crude oil procurement will then just be added to the import planaccording to their refining margin and only inventory limits will haveto be considered. As such a pre-qualification process would limit theprofitability of the refinery by limiting the potential crude oil procure-ments, this was not considered a feasible direction for furtherdevelopment.

5.1.2. Mitigate problems related to target tasksThe difficulty in selection of crudes is that feasibility evaluation

requires detailed scheduling of a long time-horizon (2–3 months)where a variety of uncertainties exist. There are basically two ways ofdealingwith this: (i) reduce the time horizon, or (ii) improve the abilityto perform the detailed scheduling and deal with the stochasticity.

The first option requires that traders can secure crude deliveries at ashort notice. This will make the data deterministic and feasible toschedule with existing processes. This could be achieved by creating aDSS that spans the mid-term and the short-term planning, which cancoordinate operation of multiple facilities. If the portfolio containsenough heterogeneous facilities, crudes can be bought long-termwithout considering feasibility. On the mid-term and the short-termhorizon the DSS then distributes the procurements between the differ-ent refineries in a way that ensures feasibility and maximizes profit. Asthis study focuses on the Kalundborg refinery, this network perspectivewould be out of the scope of this study, and this direction was notpursued, as the product portfolio at a single refinery is too small toensure feasibility.

The second option involves the introduction of a DSS to support theselection task based on an improved anticipation of the detailedplanning, which should reduce the time required to select crudes andimprove the ability to choose the right crudes. Such a DSS would spanthe mid-term planning level. In our study, this option was selected as



Table 2Requirements for new DSS.

Key issues DSS requirements

1 Deciding upon an import plan is a time-consuming process for the traders and theplanners, because of the many iterations andlengthy feasibility studies necessary to select theright procurements.

Reduce resources spent onprocurement planning

2 It is not possible to assess how good an importplan is in absolute terms. As only a fewalternatives can be assessed, the chosen solutionmight be far from the, not-considered, bestsolution.

Enable assessment ofopportunity cost

3 The complexity of the selection problemencourages the planners to stick with the well-known crude oils, even though they could be lessprofitable than “exotic” crudes with morecomplicating component contents.

Increase refining profits

4 The selection and validation processes dependon the experience and insight of a few keyemployees.

Reduce dependency on tacitknowledge

5 It is difficult to react to suddenly availableprocurements, as a new schedule cannot becreated in time.

Reduce response time tomarket opportunities


(i) it involves a relative generic decision problem with a hierarchicalanticipation dimension, which increases the relevance of our study inthe literature, and (ii) it can build on a significant body of industrialexperience and academic literature available on detailed scheduling.In Fig. 7 we have placed the DSS in the hierarchical planning systemaccording to this option and shown the performance criteria for eachof the actors responsible for the respective planning levels, as well asdecision aggregation level and organizational scope of the planningprocesses.

Our choice of organizing the DSS at the mid-term planning level,focusing on handling the task “Select among procurement opportuni-ties”, adds a series of requirements to the DSS. From Fig. 7 we candeduce the following:

1. The aggregation level of the decisions takenby theDSSmust be in themagnitude of days.

Fig. 7. For Statoil's case, the DSS will have to


2. The system will be instructed on crude netbacks and productiontargets and must instruct the short-term planners on the importplan and the corresponding target aggregated flow schedule. To dothis it will need to make anticipations regarding the short-termplanning level (e.g. actual CDU feed requirements, exact crudedelivery dates).

3. Decisions taken will concern only the refinery in Kalundborg. Thismeans that the support system will consider details of the refinery,including equipment capacities and operation times.

4. The users of the software will likely be the Planning & Economics orthe Trading department.

5. Import plans (and flow schedules) must be optimized against therefining profits of Kalundborg.

To decide if the system should be used by the Trading department orthe Planning & Economics department, we will evaluate the degree ofautomation and characteristics of the left-over tasks of the crude selec-tion subproblem, as suggested by van Wezel et al. [49]. The maindistinction is whether the user will simply have to provide input data,or will be an active participant in the decision process.

5.2. The process

Fig. 8 shows all the information we have on the DSS at this stage ofthe development process. It receives instructions regarding crudenetbacks and the volumetric production targets, and it instructs theshort-term planning with import and crude flow plans. The systemrequires a range of static information (refinery setup, crude assays,etc.) and is subject to constraints based on a set of exogenous variables(information). The aggregation level of the DSS will be the highesttemporal granularity of the exogenous variables. In our case study,details on the equipment availability are on a daily basis and procure-ment contracts are negotiated for three-day delivery windows. Thetemporal granularity of any data produced by the DSS will thereforebe at least three days.

The system will have to anticipate the short-term planning level,when evaluating if the instructions will be feasible on that level. It willthus have to anticipate the mechanics of the detailed crude flow in the

span the medium term planning level.



Fig. 8. Depiction of the information flows to and from the DSS.


crude operations system. It is important that the anticipation of theshort-term planning level is as precise as practically possible, to easedisaggregation of the solution. Even if wewere able to perfectly forecastthe data, the combinatorial nature of the scheduling task (that is centralin the base level) renders it practically impossible to solve a perfectanticipation. Instead we use implicit anticipations, and design the

Fig. 9. Proposed new procurement process. Calculations of netbacks an


process so that these are continuously updated and improved. Whenusing implicit anticipations, the left-over tasks of the selection subprob-lem are non-trivial; the usermust be able to identify potential flaws andmake adjustments to guide the DSS in another direction.

Since the Trading department has no prior experiencewith planningand scheduling, it becomes natural that the Planning & Economics

d related tasks, which lie within long-term planning, are omitted.




department should be the primary user of the system. Fig. 9 shows theproposed new procurement process, where the software componentof the DSS is a central part in the selection task.

5.3. The software

The overall architecture of the DSS software can be derived from thetarget process in Fig. 9. First, we note that the softwarewill need to storetwo types of information, dynamic case-specific data, and more staticknowledge-base data. The dynamic data includes all information regu-larly flowing into the system, e.g. production targets and initial invento-ry. The static data includes the refinery setup information and theimplicit anticipation model (although the model definition is definedby the problem processing system). Since no data is completely static,the software will also need a knowledge editor. Traders, planners andschedulers have a series of existing systems that the software willhave to interface with and it thus needs an integration system and/ora report generator, depending of the nature of the interface. Fig. 10shows the architecture that, besides the mentioned elements of therepresentation system, also needs a problem processing system todeal with the scheduling task.

5.3.1. Problem processing systemWhen we chose to position the DSS at the mid-term planning level,

and not change pre-qualification of other long-termplanning processes,we retained the CDU feed's dependency on crude oil blending, and theDSS thus needs to consider scheduling explicitly. The algorithm usedto solve the problem in our DSS is based on Oddsdottir et al. [35] anduses scheduling algorithms based on the crude scheduling literature[30,39] to solve the reduced MINLP model. A detailed discussion ofthis modeling approach is out of the scope of this paper, and interestedreaders are referred to the mentioned references.

5.3.2. The anticipation modelBecause we chose to use an imperfect anticipation it will be neces-

sary to note how data is aggregated and what measures are taken tomake the aggregation robust. First of all, the primary output of thesystem is the import plan. The choice of a discrete-time schedulingmodelmeans thatwewill aggregate data to represent the 3-day periodsthat make up the total planning horizon, which is 3 months. In realitywe only need to model the second and the third month (20 periods),due to the fact that procurement agreements for the first month cannot

Fig. 10. General architectur


be changed anymore. In Statoil's detailed scheduling process, all aspectsof technical feasibility, roughly 290 parameters, are evaluated to ensurethat the facility can run without interruption. Some parameters arecritical, while other parameters almost always have acceptable valueswhen some “key” parameters are within their limits. It is not computa-tionally feasible to handle an MINLP model that covers 20 periods andall 290 parameters. In collaboration with Statoil, we therefore selected11 key parameters that presented an acceptable balance betweenmodel complexity and anticipation quality:

• 2 volumetric flow parameters• 3 crude blend components or characteristics, measured for 2 CDUsand for the total system: sulfur (wt.%), TAN (ppm), and density(g/cm3).

Component limits to the total system (sum of CDUs) and thevolumetric flow limits are critical to ensure feasible operation of thedownstream system, the end-product operations. The component limitsspecific to each CDU are necessary because each CDU has its ownfeedstock range.

Following the terminology of Schneeweiss [43], this classifies asimplicit anticipation since we choose parameters that indicate thedynamics of the base-level system. The specific limits on each of theparameters are some of the controls available to improve the anticipa-tion model: enlarging, shrinking or moving the accepted intervals.Once the optimization module has found an optimal solution, the DSScan easily calculate and present all the 290 parameters to the user. Assolution algorithms and CPU power improve, model managers couldalso choose to add more key parameters, to further improve the antici-pation quality.

The reduction of the problem complexity may lead to discrepancybetween the anticipated base level and the actual base level, and canevenprevent the aggregated solution frombeing feasibly disaggregated.The DSS uses two strategies to improve the likelihood of finding asolution that is robust to disaggregation.

First, the DSS software lets planners dedicate groups of storage tanksto each of the CDUs, meaning that the average key component level ofeach group will meet the limitations of the related CDU. This preventssolutions that are just narrowly acceptable, meaning solutions wherecomponent limits can only be met from the final blend in the manifoldbetween storage tanks and CDU — where small changes to equipmentavailability will render the plan infeasible. Instead, multiple tanks willnow hold crude blends that can be accepted by the CDUs.

e of the DSS software.



Fig. 11. Realization of DSS software architecture with the indication of information streams and direction of interaction.


Second, we expanded the crude assay data for each crude and let itbe dependent on which CDU a specific crude flowed to in each period.The reason for maintaining data separate for each CDU is to controlthe key component levels of the end products when blending heavy


crudes with light crudes. A large fraction of heavy crudes is distilledinto heavy end products. If the TAN level of these products is too high,one might want to reduce this by blending the heavy crude with acondensate that is low on TAN. The problem is that condensates distil




to very small amounts of heavy end products and blending is thus notlinear to the volume flow of the crude. The additional implicit anticipa-tions used to counter this is to add bonus values or punishment to thecrude assay data dependent on which CDU the crude goes into. Forexample, in the current anticipation model, the TAN level for conden-sates with densities under 0.77 g/cm3, is set to 0.45 ppm when goinginto the non-condensate CDU and the original 0.01 ppm when goinginto the condensate CDU. In this way, we can prohibit or decrease theusage of condensates to artificially lighten or dilute heavier crudes,and vice versa. This increases the likelihood that a solution can be feasi-bly disaggregated.

In conclusion, the likelihood of finding a feasible solution can beincreased by (i) making the parameter limits for the aggregatedmodel tighter to create room for “nudging” the plan when disaggregat-ing, or (ii) using one of the two strategies described above.

5.3.3. Representation systemsFrom Fig. 9, we know that the different users of the system will be

interested in different aspects of the software:

• The Trading department holds the task of finding specific procure-ments in the market and will regularly need to update information,as up-to-date information is critical to the process.

• The Scheduling department needs to validate the solution and thusneeds access to the generated flow schedule and detailed metadatato assist disaggregation and validation.

• Planning & Economics is interested in finding import plans, based oninput regarding already agreed procurements, the base stock slate,and the procurement opportunities. They will also need access tothe implicit anticipation model, so they can update key componentlimits, tank dedication limits, and crude assay bonus levels. Finally,they will need a solution report from the system with metadata thatcan guide them in assessing the feasibility of the solution.

We have split the user interface into compartments that support thestructure of the procurement process. This ensures that the user inter-face can be customized to each user's own work stream. It thus allowsthe individual user to go through the system-user adaptive processthat is essential for a DSS and is in line with the request for better userinterface personalization put forth by Shim et al. [44].

To illustrate the resulting DSS architecture, Fig. 11 shows, through acollection of connected screenshots, the elements of the developed DSS.It indicates how different users have their separate interface, and itshows how they can use the system without having to worry aboutthe layer with mathematical and algorithmic details.

The fact that such a layer exists, however, means that Statoil willneed a model manager that can maintain it. This is a clear example ofhow the DSS affects the organization, as Keen [23] predicted. The specif-ic interface between the model manager and the algorithmic layerdepends on how Statoil chooses to organize themselves and is thereforeoutside of the scope of this paper. The General Algebraic ModelingSystem, GAMS, was used to implement the heuristic. In the case study,we acted as model managers and interfaced with the source code,written in GAMS syntax, directly.

The proposed DSS contains another layer, the commercial solver,which could be any available and viable solution. For our prototype,we have used IBM's MIP solver CPLEX. This is also a consequence ofthe chosen heuristic that breaks the problem into a sequence of MIPs.

The user interface layer was implemented in Microsoft Excel, as it isthe environment that many other planning tools at Statoil utilize.Seamless integration with the detailed scheduling tools and netbackcalculators is ensured simply by reusing data structures. To optimizethe problem processing system, data structures are in some casesaltered before being sent to the commercial solver. The choice ofMicrosoft Excel also allowed us to use Excel's data visualization system,integration system, and user interface platform, rather than developingthem ourselves.


5.4. Case study results

A comprehensive numerical study of theplanningmodel is notwith-in the scope of this paper. For more details on the algorithmic perfor-mance, we refer to Oddsdottir et al. [35]. Here, we will howeverbriefly discuss some results related to the DSS requirements set out inTable 2.

The DSS has been tested with Statoil staff and the DSS softwareaspects have been tested against historic data. A total of 91 tests wereperformed, based on 6 base cases and 4 use case scenarios (adding hold-ing cost, rolling horizon planning setup, rescheduling in response todifficulties, and reschedule to take advantage of suddenly appearingprocurement opportunities). Based on these tests,we expect the follow-ing changes in the key metrics introduced earlier:

• An increase in the refining profit by at least 10%, due to an increasedability to assess profitable procurement opportunities.

• A reduction of about 60% in procurement process resource usage, asmany time-consuming, computationally difficult tasks have beenimplemented in the software.

• A reduction from 14 days to just 1 day for the import plan lead time,mainly due to a significant decrease in iterative communicationbetween different departments in the organization. Combined, weestimate that the improved procurement process allows the organiza-tion to improve its local refining profit by 10%.

Next to thesemore quantitative results, theDSS has also reduced thedependence on tacit knowledge, which reduces the training of new staffsignificantly, as well as increased the possibilities to compare alterna-tive plans, which was too time-consuming before.

6. DSS development methodology

Based on experiences from the case study, we are able to furtherspecify our initial conceptual framework to propose a DSS developmentmethodology, applicable when developing for hierarchically structuredAPSs.

A design task, at its most basic level, tries to fulfill a set of require-ments by realizing a performance of something or someone. Theserequirements are typically identified through an analysis task and theperformance is a characteristic of the creation. With DSSs, we designin sequential stages (disregarding naturally occurring iterations). Firstwe design the organization aspect of the DSS, then the process, andlastly the software aspect. So DSS development can be seen as a processthat continuously transforms required performance to realized perfor-mance, while continuously updating the requirements so they fit therealized parts of the DSS.

Fig. 12 shows the resulting DSS development methodology. A set ofrequirements may be considered and relevant for the development of aspecific aspect, but not possible to realize within that aspect of the DSS.Instead, such requirements are updated with the knowledge generatedin the task and passed back to the pool of requirements.

The full process is as follows. Before the development commences,the designer analyzes the current decision process. The output of thisis the base requirements for the DSS, on which the development isinitiated.

First, the designer extracts a part of the base requirements andrealizes someof themby creating the decision organization (positioningthe DSS within the APS and its organizational embedding). The require-ments that are not realized are further specified to fit the chosen deci-sion organization and used in the next stage. This also holds for theknowledge regarding the decision characteristics and planninginteractions, which cover:

• Decision characteristics: Decision objectives, organizational scopeof decision, decision aggregation level, and required performance ofdecision process.



Fig. 12. Illustration of proposed method for designing DSS systems for a hierarchically structured planning system.


• Planning interactions: Involved organizational units (departments),instructions received from higher planning levels, instructionspresented to lower planning levels, necessary anticipations, and infor-mation available to the process.

Second, the designer develops the process aspect of the DSS, basedon the updated requirements as well as the base requirements for thefuture process. The product of the process development task is thenew decision process structure and, as before, a set of further specifiedrequirements, namely the necessary model characteristics and userinteractions, which cover:

• Model characteristics:Model objectives, scope ofmodel, model aggre-gation level, and required model performance.

• User interactions: Users, input to software, output from software,specific applications of software.

Third, this information is used, together with requirements from theoverall performance requirements, to develop the software aspect ofthe DSS and thereby “finalizing” the DSS development with the creationof a software system. Because software development has no descen-dants, it will need to realize all the requirements that are left. Whenthe software development task is done, we conclude the DSS develop-ment. This approach would be repeated when another or new decisioninadequacy is identified.

7. Conclusions

In this paper, we develop a design framework for decision support inhierarchical planning systems. Building on a case study on the develop-ment of a DSS for procurement planning within a typical hierarchicallystructured APS, we illustrated (i) howDSS practitioners can use analysisof organized decision systems to propose new decision processes thatutilize model-based DSS software, and (ii) how process and organiza-tion design can direct the development of such software. Finally, wecondensed our experiences into a three-stage DSS development


process. The results of the case study indicate significant savings interms of planning efforts and procurement costs, improving theprocurement planning aspects in APSs for refining industries. Moregenerally, our framework should be able to support the continuousimprovement of advanced planning systems, adding planning function-alities or improving existing functionalities, with a focus on the organi-zational embedding of the different planning tasks, thereby increasingoverall planning quality in complex supply chains.

In this paper, the refining industry is used as the specific context,and the identified organization, process, and software, as well as theresulting savings are of course dependent on case specifics. Never-theless, it is important to realize that the hierarchical planning struc-ture that is at the core of this research is commonly found inindustry. It is reflected in most organizational structures of mediumand large sized companies, as well as in commercially available APSs,by large vendors such as SAP or AspenTech [47]. It is furthermoreused as a decomposition method in the development of planningtools in many industries, ranging from typical manufacturing situa-tions in which aggregate planning strategies based on product fami-lies are followed by detailed planning for individual products, tomore industry-specific applications where some kind of decouplingbetween planning problems with different granularities can be iden-tified. It should be noted that the development of anticipation mech-anisms connecting the different planning levels is usually problem-specific and requires good domain knowledge. The anticipationmechanisms developed in the case study cover aspects that are typ-ical for process industries, and could for instance also be applicable inother industries where varying raw material quality is a key factor,such as the food industry, the chemical industry, or the paper indus-try. For this paper, the key is that the anticipation is representativefor the type of connections that are needed between planning prob-lems in hierarchical planning structures. In general, the case pro-vides an example of a typical hierarchical planning situation,supporting the general applicability of the framework in the devel-opment of decision support in hierarchical planning systems.




Throughout the software development task, the anticipation model,especially the crude-tank group dedication and bonus crude assay data,has been continuously updated aswe tested the system against the spe-cific procurement issues encountered at Statoil. This has brought theDSS software to a point, where disaggregation of the solution can bedone feasibly and the prototypeDSS software can be tested on reliabilityand robustness. If successful, the next step will be to create a “profes-sional grade” system, with adequate linkage in to the IT infrastructureand maintenance features. A crucial ability in this effort is to be able tomeasure and ensure the performance of the DSS. How do we validatethe robustness of the aggregation rules applied? How can we identifycauses of decision effectiveness issues when discrepancies betweenreality and the DSS software are only accessible through the planner'smental model of both realities?

The abovementioned questions are interesting directions for furtherresearch as well. Also, even though we trust the proposed developmentmethodology to be relatively generic, it would be useful to test it inother APS development projects. An important aspect of our work isthe anticipation functions in hierarchical settings, even though thedeveloped methodology might also be used outside of hierarchicalplanning settings. Related to our case study, another interesting direc-tion for further research stems from our focus on a single productionfacility. Extending the DSS to include a production network with multi-ple facilities would create additional opportunities to improve refiningmargins, but the organizational embedding of the DSS would alsorequire additional attention.

Acknowledgments

We gratefully acknowledge our collaboration partners at Statoil A/Sfor providing useful information and support regarding this work.

References

[1] R.L. Ackoff, Management misinformation systems, Management Science 14 (1967)B-147–B-156.

[2] S. Alter, A taxonomy of decision support systems, Sloan Management Review 19(1977) 39–56.

[3] S. Alter, A work system view of DSS in its fourth decade, Decision Support Systems38 (2004) 319–327.

[4] D. Arnott, G. Pervan, Eight key issues for the decision support systems discipline,Decision Support Systems 44 (2008) 657–672.

[5] G.R. Bitran, E.A. Haas, H. Matsuo, Production planning of style goods with high setupcosts and forecast revisions, Operations Research 34 (1986) 226–236.

[6] R.W. Blanning, The functions of a decision support system, Information &Management 2 (1979) 87–93.

[7] J.S. Bonser, S.D. Wu, Procurement planning to maintain both short-termadaptiveness and long-term perspective, Management Science 47 (2001)769–786.

[8] J.C. Courbon, J. Grajew, J. Tolovi, Design and Implementation of Interactive DecisionSupport Systems: An Evolutive Approach, Institute d'Administration desEnterprises, Grenoble, France, 1978.

[9] Y. Crama, R. Pascual, J.A. Torres, Optimal procurement decisions in the presence oftotal quantity discounts and alternative product recipes, European Journal ofOperational Research 159 (2004) 364–378.

[10] L. De Boer, E. Labro, P. Morlacchi, A review of methods supporting supplier selection,European Journal of Purchasing & Supply Management 7 (2001) 75–89.

[11] G. Fontan, C. Merce, J.-C. Hennet, J. Lasserre, Hierarchical scheduling for decisionsupport, Journal of Intelligent Manufacturing 16 (2005) 235–242.

[12] A. Gachet, P. Haettenschwiler, Development processes of intelligent decision-making support systems: review and perspective, in: J.N.D. Gupta, G.A. Forgionne,T.M. Mora (Eds.), Intelligent Decision-making Support Systems: Foundations,Applications and Challenges, Springer, 2006, pp. 97–121.

[13] H. Gfrerer, G. Zäpfel, Hierarchical model for production planning in the case ofuncertain demand, European Journal of Operational Research 86 (1995)142–161.

[14] I.E. Grossmann, Advances in mathematical programming models for enterprise-wide optimization, Computers & Chemical Engineering 47 (2012) 2–18.

[15] A.C. Hax, H.C. Meal, Hierarchical integration of production planning and scheduling,in: M. Geisler (Ed.), TIMS Studies in Management Science, North-Holland,Amsterdam, 1973, pp. 53–69.

[16] C.W. Holsapple, A.B. Whinston, Decision Support Systems: A Knowledge-basedApproach, West Publishing Company, St. Paul, MN, USA, 1996.

[17] Z. Hong, C.K.M. Lee, A decision support system for procurement risk management inthe presence of spot market, Decision Support Systems 55 (2013) 1–36.


[18] K. Inderfurth, P. Kelle, R. Kleber, Dual sourcing using capacity reservationand spot market: optimal procurement policy and heuristic parameterdetermination, European Journal of Operational Research 225 (2013)298–309.

[19] V. Jayaraman, R. Srivastava, W.C. Benton, Supplier selection and order quantityallocation: a comprehensive model, Journal of Supply Chain Management 35(1999) 50–58.

[20] P. Jonsson, L. Kjellsdotter, M. Rudberg, Applying advanced planning systems forsupply chain planning: three case studies, International Journal of PhysicalDistribution & Logistics Management 37 (2007) 816–834.

[21] N. Julka, I. Karimi, R. Srinivasan, Agent-based supply chain management—2: arefinery application, Computers & Chemical Engineering 26 (2002) 1771–1781.

[22] P.G. Keen, M.S. Scott-Morton, Decision Support Systems: An OrganizationalPerspective, Addison-Wesley, Reading, Massachusetts, 1978.

[23] P.G.W. Keen, Adaptive design for decision support systems, SIGOA Newsletter 1(1980) 15–25.

[24] B.G. Kingsman, Purchasing raw materials with uncertain fluctuating prices,European Journal of Operational Research 25 (1986) 358–372.

[25] M.R. Klein, L.B. Methlie, Knowledge Based Decision Support Systems: WithApplications in Business, 2nd ed. John Wiley & Sons Inc., West Sussex, England,1995.

[26] L.Y. Koo, A. Adhitya, R. Srinivasan, I.A. Karimi, Decision support for integratedrefinery supply chains— part 2, Design and operation, Computers & Chemical Engi-neering 32 (2008) 2787–2800.

[27] H. Lakkhanawat, M.J. Bagajewicz, Financial risk management with product pricing inthe planning of refinery operations, Industrial & Engineering Chemistry Research 47(2008) 6622–6639.

[28] W. Lasschuit, N. Thijssen, Supporting supply chain planning and schedulingdecisions in the oil and chemical industry, Computers & Chemical Engineering 28(2004) 863–870.

[29] J.B. Lasserre, C. Mercé, Robust hierarchical production planning under uncertainty,Annals of Operations Research 26 (1990) 73–87.

[30] J. Li, W. Li, I.A. Karimi, R. Srinivasan, Improving the robustness and efficiency ofcrude scheduling algorithms, AIChE Journal 53 (2007) 2659–2680.

[31] H. Linger, F. Burstein, Intelligent decision support in the context of the modernorganisation, Proceedings of the 4th Conference of the International Society forDecision Support Systems — ISDSS'97, July 21–22, Lausanne, Switzerland, 1997.

[32] K.N. McKay, V.C.S. Wiers, Integrated decision support for planning, scheduling, anddispatching tasks in a focused factory, Computers in Industry 50 (2003) 5–14.

[33] H. Meyr, H. Rosic, C. Seipl, M. Wagner, U. Wetterauer, Architecture of selected APS,in: H. Stadtler, C. Kilger (Eds.), Supply Chain Management and Advanced Planning,4 ed.Springer, Berlin, 2008.

[34] S.M.S. Neiro, J.M. Pinto, A general modeling framework for the operational planningof petroleum supply chains, Computers & Chemical Engineering 28 (2004) 871–896.

[35] T.A. Oddsdottir, M. Grunow, R. Akkerman, Procurement planning in oil refiningindustries considering blending operations, Computers & Chemical Engineering 58(2013) 1–13.

[36] L. Özdamar, M.A. Bozyel, S.I. Birbil, A hierarchical decision support system forproduction planning (with case study), European Journal of Operational Research104 (1998) 403–422.

[37] S.S. Pitty, W. Li, A. Adhitya, R. Srinivasan, I.A. Karimi, Decision support for integratedrefinery supply chains — part 1. Dynamic simulation, Computers & ChemicalEngineering 32 (2008) 2767–2786.

[38] D.J. Power, Decision Support Systems: Concepts and Resources for Managers,Quorum Book, Westport, CT, USA, 2002.

[39] P.C.P. Reddy, I.A. Karimi, R. Srinivasan, Novel solution approach for optimizing crudeoil operations, AIChE Journal 50 (2004) 1177–1197.

[40] M. Roitsch, H. Meyr, Oil industry, in: H. Stadtler, C. Kilger (Eds.), SupplyChain Management and Advanced Planning, 4 ed.Springer, Berlin, 2008,pp. 1–16.

[41] K. Saxena, Decision support engineering: a DSS development methodology,Proceedings of the Twenty-fourth Annual Hawaii International Conference onSystem Sciences, IEEE, 1991, pp. 98–107.

[42] C. Schneeweiss, Hierarchical structures in organisations: a conceptual framework,European Journal of Operational Research 86 (1995) 4–31.

[43] C. Schneeweiss, Distributed decisionmaking— a unified approach, European Journalof Operational Research 150 (2003) 237–252.

[44] J.P. Shim, M. Warkentin, J.F. Courtney, D.J. Power, R. Sharda, C. Carlsson, Past,present, and future of decision support technology, Decision Support Systems 33(2002) 111–126.

[45] D.E. Shobrys, D.C. White, Planning, scheduling and control systems: why can theynot work together, Computers & Chemical Engineering 24 (2000) 163–173.

[46] H.A. Simon, The structure of ill structured problems, Artificial Intelligence 4 (1974)181–201.

[47] H. Stadtler, C. Kilger (Eds.), Supply ChainManagement and Advanced Planning, 4 ed.Springer, Berlin, Germany, 2008.

[48] H. Stadtler, B. Fleischmann, M. Grunow, H. Meyr, C. Sürie, Advanced Planning inSupply Chains, Springer, Berlin, Germany, 2012.

[49] W. van Wezel, J. Cegarra, J.-M. Hoc, Allocating functions to human and algorithm inscheduling, in: J.C. Fransoo, T. Wäfler, J.R. Wilson (Eds.), Behavioral Operations inPlanning and Scheduling, Springer, Berlin, Heidelberg, 2011, pp. 339–370.

[50] E. Vicens,M.E. Alemany, C. Andres, J.J. Guarch, A design and applicationmethodologyfor hierarchical production planning decision support systems in an enterpriseintegration context, International Journal of Production Economics 74 (2001) 5–20.

[51] A.J. Zoryk-Schalla, J.C. Fransoo, T.G. de de Kok, Modeling the planning process inadvanced planning systems, Information & Management 42 (2004) 75–87.


http://refhub.elsevier.com/S0167-9236(14)00231-0/rf0245
































































































































K.B. Kallestrup et al. / Decision Suppo

Kasper Bislev Kallestrup received an M.Sc. in Engineering Management from theTechnical University of Denmark, where he subsequently also worked in researchpositions in the Department of Management Engineering and the Department ofChemical Engineering.

Lasse Hadberg Lynge received an M.Sc. in Engineering Management and a B.Sc. inMechanical Engineering from theTechnical University ofDenmark. After holding positionsat IBM and Victoria Properties, he is currently working as a Consultant at Bain & Company.

RenzoAkkerman is Professor of OperationsManagement and Technology at the School ofManagement of the Technische Universität München in Munich, Germany. He previouslyheld positions at the Technical University of Denmark and theUniversity of Groningen. Hehas a Ph.D. inOperationsManagement, aswell as anM.Sc. in Econometrics andOperationsResearch, both from theUniversity of Groningen.His research and teachingmainly focuseson operations management in the process industries, ranging from supply chainmanagement issues to detailed production planning and control.


Thordis Anna Oddsdottir is a Ph.D. student in the Department of ManagementEngineering at the Technical University of Denmark. She holds an M.Sc. in IndustrialEngineering from the Georgia Institute of Technology, as well as a B.Sc. in MechanicalEngineering from the University of Iceland. Her research interest lies within the fieldof operations management, with special focus on supply chain management andoptimization.

15rt Systems xxx (2014) xxx–xxx



decision support systemskianaco.net/download/articles/2014/10.1016-j.dss.2014.09.003-decision... ·...

Documents