Risk Assessment Framework for Outbound Supply-Chain Management

Abstract

We developed a framework for the risk assessment of delaying the delivery of shipments to customers in the presence of incomplete information pertaining to a significant, e.g., weather-related, event that could cause substantial disruption. The approach was anchored in existing manual practices, but equipped with a mechanism for collecting critical data and incorporating it into decision-making, paving the path to gradual automation. Two key variables that affect the risk were: the likelihood of an event and the importance of the specific shipment. User-specified event likelihood, with elliptical spatial component, allowed the model to attach different probabilistic interpretations; uniform and Gaussian probability distributions were discussed, including possible paths for extensions. The framework development included a practical implementation in the Python scientific ecosystem. Although the framework was demonstrated in a prototype environment, the results clearly showed that the framework was quickly able to show scheduled and in-process shipments that were at risk of delay, while also providing a prioritized ranking of these shipments in order for personnel within the manufacturing organization to quickly implement mitigation actions and proactive communications with customers to ensure critical shipments were delivered when needed. Since the framework pulled in data from various business information systems, the framework proved to assist personnel to quickly identify potentially impacted shipments much faster than existing methods, which resulted in improved efficiency and customer satisfaction.

1. Introduction

In the modern commerce era, many companies have a global presence and rely upon complex supply chains in order to meet customer demand and improve the customer experience (CX). Unexpected events (extreme weather, pandemic, labor strikes, political unrest, etc.) can have severe ramifications that extend throughout the entire supply chain. As our society has advanced in digitization and the availability of data, businesses are working on ways to utilize newly available supply-chain-related data to not only improve their operations, but also to provide awareness of unexpected disruptive events and to know whether, why, how, and with whom they should interact to take proactive mitigation steps to minimize the impact of an expected event onto its business and its customers. Current business processes often require information to flow in a disconnected fashion involving multiple stakeholders. As a result, risk mitigation decisions applied to pending customer shipments may take hours to days, or in some cases, may not happen at all. The risk assessment framework described in this article is part of a larger system that is intended to improve the speed and accuracy of information flowing through business processes such that mitigation decisions can be made in hours or seconds and proactively communicated with customers, yielding improvements in customer experience.

A supply chain is defined as a network of firms that may include suppliers, manufacturers, distributors, retailers, freight transporters, logistics, warehouses, and even customers. Supply chain management (SCM) is the field of study focused on managing the procurement, movement, storage of materials, parts, and finished inventory through an organization in order to fulfill customer orders [1]. The existing SCM literature is vast, and there are two branches of research that are most relevant to this current work, supply chain risk management (SCRM) and supply chain event management (SCEM). SCRM is focused on efficiently managing disruptions and uncertainty in supply chains [1]. SCRM typically involves the following steps:

• Risk Identification.
• Risk Assessment.
• Risk Modeling.
• Risk Mitigation.
• Risk Monitoring.

SCEM is defined as an event-based business process whereby significant disruptive events are recognized in a timely manner, actions are quickly triggered, material and information flows are adjusted in some way, and key personnel (internal and external) are immediately notified [2]. Bearzotti et al. [2] identify SCEM systems based on a level of automation that could support a company’s overall SCEM goals. They are:

• Monitoring system—which would allow a user to monitor planned (known) events and be able to detect disruptive events.
• Alarm system—which would systematically detect variations to a schedule and notify key personnel based on predefined threshold levels.
• Decision support system—which would detect deviation and find a solution that minimizes the disturbance impact on the supply chain, and the proposed solution would then be provided to the human decision-maker to make the final decision.
• Autonomous corrective system—which would be able to detect a disruptive event, verify the feasibility of the current schedule, or look for a solution to repair the schedule, and if a solution exists, implement it.

The risk assessment (RA) module described in this article is a contribution to the SCEM literature, and would generally be categorized as a “decision support system” based upon the levels of automation for SCEM systems as identified by [2]; however, since the development of the RA module was the outcome of an attempt to solve a practical problem and a specific use case applied to outbound shipments, a suitable framework that satisfied the constraints was not found in the SCRM and SCEM literature. The RA module has several distinguishing features that are noteworthy. First, the RA module provides a user interface that allows an SCEM analyst to identify a potential event in both space and time and see the scheduled outbound shipments that may be impacted by the event. Furthermore, the RA module determines a risk score for each shipment that is based upon (1) company specific criteria (in this case a combination of five weighted customer variables), and (2) an assessment of the likelihood of the possible event. Although the intended use case is to provide insight to the SCEM analyst regarding impacts to outbound shipments for a future event, the RA module also has value for quickly showing impacted shipments for an existing event. Since the RA module provides a risk score for each shipment, under the case when an event is known, the RA module can be used to prioritize intervention actions based on each shipment’s risk score.

2. Key Framework Parameters

The proposed framework is based on importance of an individual shipment and the probability of an event. Two parameters were formulated to capture their significance: shipment priority score and subjective assessment of likelihood. They are discussed in the subsequent sections.

2.1. Importance of Individual Shipments

The shipment priority score (SPS) $s_{ps}$ was introduced as a metric that quantifies the importance of a specific shipment. SPS was modeled as a weighted sum of a finite number of n normalized customer variables ${\overline{c}}_{v{n}_i}$

$$s_{ps}=\sum _{i=1}^n{w}_i{\overline{c}}_{v{n}_i},$$

(1)

where $w_i$ are the associated weights. A customer variable $c_v$ takes values from a finite set of discrete and ordered values, e.g., customer ranking can be modeled as (please note the specific customer variable is fictitious and is here for illustrative purposes only)

$$c_v\in \{\mathrm{high},\mathrm{very}\mathrm{high},\mathrm{critical}\},$$

(2)

The process started with a business unit manager assigning numerical values to the categories, as illustrated in

Table 1. An example mapping between categories and their associated numerical values.

Category	Numerical Value	Normalized Value
${\mathit{c}}_{\mathit{v}}$	${\mathit{c}}_{\mathit{vn}}$	${\overline{\mathit{c}}}_{\mathit{vn}}$
high	3	0.375
very high	4	0.500
critical	8	1.000

. Note that the values were subjectively assigned to intuitively capture the relative difference among the categories. In the conceptual example shown in Table 1, the high and very high are relatively close, whereas critical is of considerably higher importance.

To prevent multiple scales associated with different customers from affecting the weights of Equation (1), the customer variables were scaled to 0–1 range before they were used in the sum. The scaling was achieved simply by dividing a numerical value of a customer variable by its maximum possible value for that variable

$${\overline{c}}_{v{n}_i}=\frac{c_{v{n}_i}}{max\left(c_{v{n}_i}\right)}$$

(3)

This normalization provided freedom to a business unit manager when assigning numerical values to the categories of customer variables, allowing them to select whatever scale may be intuitive to them, while keeping the weights $w_i$ unaffected and allowing them to encode only relative importance of different customer variable to the specific business unit.

Within an organization, different business units can customize their customer variables with their numerical values. Business units can employ different weights to express their specific perspective on the relative importance of different customer variables.

2.2. Probability of an Event

In the context of risk assessment and risk management, the probability of an event is typically considered as a subjective assignment, sometimes referred to as a personal probability, in the tradition of [3]; other times as plausibility [4], or belief [5]. In practice, this probability can be obtained directly from an analyst, as a subjective assessment of likelihood (SAL); other times it can be the result of a statistical, computational module. In both cases, the probability estimate of an event is denoted $p_{SAL}$.

The proposed metric SAL is a categorical variable with five intuitive states: informational, possible, likely, very likely, and imminent. A numerical mapping of these variables are summarized in

Table 2. Subjective assessment of likelihood.

Category	Probability Range
Imminent	0.95–1.00
Very likely	0.80–0.95
Likely	0.50–0.80
Possible	0.30–0.50
Informational	0.00–0.30

. As suggested in its name, SAL is a subjective metric. Categories and their associated probability ranges can be adjusted according to the user’s needs and preferences.

3. Geofencing and Risk Assessment

3.1. Event Geofencing and Its Relation to Probability

In the manual mode, an analyst supplied the geofence that defined the region affected by an event, using a flexible shape in the form of a tilted ellipse, characterized by five parameters: latitude ${\phi }_c$ and longitude ${\lambda }_c$ of the center, lengths of the two semi-axes a and b, and the tilt $\theta$, as illustrated in Figure 1a. While free-form shapes gave an analyst more flexibility in outlining a region of space, they also required more effort. Moreover, simple shapes—fully defined by a few parameters—were easier to modify, track, and store the history of their changes. These features were identified as important to deal with the evolving uncertainties associated with events. Because an ellipse was defined in the longitude–latitude space, it was straightforward to test if a location A defined by its coordinates $({\lambda }_A,{\phi }_A)$ was inside the geofence

$${\left(\frac{{\lambda }_A^{\prime }-{\lambda }_c}{a}\right)}^2+{\left(\frac{{\phi }_A^{\prime }-{\phi }_c}{b}\right)}^2\le 1,$$

(4)

where $({\lambda }_A^{\prime },{\phi }_A^{\prime })$ were the rotated coordinates $({\lambda }_A,{\phi }_A)$ about the center of the ellipse $({\lambda }_c,{\phi }_c)$ by the tilt angle $\theta$

$$\begin{array}{cc}{\lambda }_A^{\prime }\hfill & =\left({\lambda }_A-{\lambda }_c\right)cos\theta -\left({\phi }_A-{\phi }_c\right)sin\theta +{\lambda }_c\hfill \\ {\phi }_A^{\prime }\hfill & =\left({\lambda }_A-{\lambda }_c\right)sin\theta +\left({\phi }_A-{\phi }_c\right)cos\theta +{\phi }_c\hfill \end{array}$$

(5)

In the simplest implementation, every location within the geofence was assigned the same likelihood $p_{SAL}$, according to Table 2. Using ellipses for geofencing paves the path for refinement of the probabilistic assignment. The same elliptical shape was found useful for modeling both a uniform probability $p_{SAL}$ attached to an elliptical geofenced area and for modeling a Gaussian bi-variate probability distribution

$$p_{SAL}(\lambda ,\phi )=\frac{1}{{2\pi |\Sigma |}^{-\frac{1}{2}}}exp\left[-{(\mathbf{x}-\mathit{\mu })}^T{\Sigma }^{-1}(\mathbf{x}-\mathit{\mu })\right],$$

(6)

where $\Sigma$ is the covariance matrix

$$\Sigma =\left[\begin{array}{cc}{\sigma }_{\lambda }^2& {\sigma }_{\lambda ,\phi }^2\\ {\sigma }_{\lambda ,\phi }^2& {\sigma }_{\phi }^2\end{array}\right]=\left[\begin{array}{cc}{\sigma }_{\lambda }^2& \rho {\sigma }_{\lambda }{\sigma }_{\phi }\\ \rho {\sigma }_{\lambda }{\sigma }_{\phi }& {\sigma }_{\phi }^2\end{array}\right],$$

(7)

$\mathbf{x}$ as the vector of the coordinates $\mathbf{x}={\left[\lambda \phi \right]}^T$, $\mathit{\mu }$ is the mean vector of the distribution $\mathit{\mu }={\left[{\lambda }_c{\phi }_c\right]}^T$, and $\rho$ is the Pearson correlation coefficient. This second interpretation of the ellipse, as an equiprobable contour, has the advantage that it avoids abrupt steps in probability, which depicts the natural situation better and is very attractive to higher-level decision makers; however, it also has a disadvantage that it introduces a different way of thinking of probability assignment, which can impede the immediate adoption of the module in practice. Because the intent was to develop an extensible module, we described this interpretation in some detail, but the first implementation, described in Section 4, employed a simple uniform probability interpretation.

When modeling as a probability distribution, the ellipse signified an equiprobable surface, as depicted in Figure 1b. The semi-axis point in the direction of the eigenvalues of the covariance matrix $\Sigma$ and their length corresponds to the eigenvalues [6]. With this formulation, it was possible to attach smooth, spatially-dependent probabilities over a wider geographic region. In addition, the approach allows for a natural extension for future implementation.

Thus, two different models can be attached to the same user-defined ellipse: a uniform probability or bi-variate Gaussian distribution. The Gaussian model lends itself to additional extensions: one extension can be to employ a mixture model $p_{SAL-mixture}$, comprised of weighted Gaussian distributions $p_{Gauss}(\lambda ,\phi |Z_k)$ [7], with k components $Z_k$

$$p_{SAL-mixture}(\lambda ,\phi )=\sum _k{\alpha }_k{p}_{Gauss}(\lambda ,\phi |Z_k),$$

(8)

where each mixture components (user-defined ellipse) can have separate assessments of likelihood. The coefficients ${\alpha }_k$ are probabilities in [0, 1] range with ${\sum }_k{\alpha }_k=1$ and they would have to be computed based on the user inputs when the SAL values associated with individual ellipses are supplied. A conceptual example of a mixture, comprised of three Gaussian is illustrated in Figure 2.

The other direction for extension was to pave the path to Bayesian updating. The need for this updating can arise when the model receives multiple inputs from different users, each providing their own SAL. Conceptually, Bayesian fusion provides consistent and principled inclusion of these [8,9] inputs and provides a mechanism to appropriately weigh the reputation of the users in the form of priors. The concept of conjugate priors, introduced by [10], enables easy updates of the posterior probability distributions in analytic form, avoiding often costly numerical computations. The conjugate prior of a multivariate Gaussian is just Gaussian, but the associate conjugate prior associated with the variance is the inverse Wishart distribution. It is often preferred, that instead of updating the variance, to update its inverse, the precision $\mathit{\eta }={\Sigma }^{-1}$, with Wishart distribution $p_W$ as the conjugate prior [11]

$$p_W\left(\mathit{\eta }\right|\mathit{V},\nu )=\frac{{\left|\mathit{\eta }\right|}^{\frac{\nu -p-1}{2}}{\mathrm{e}}^{-tr\left({\mathit{V}}^{-1}\mathit{\eta }\right)/2}}{2^{\frac{\nu p}{2}}{\left|\mathit{V}\right|}^{\frac{\nu }{2}}{\Gamma }_p\left(\frac{\nu }{2}\right)},$$

(9)

where the number of degrees of freedom $\nu$ and $p\times p$ matrix $\mathit{V}$ are parameters of the distribution, with $\nu >p-1$; tr() signifies the trace of a matrix (the sum of its diagonal components) and $\Gamma \left(\right)$ is the standard gamma function. It is important to note that specifying the parameters of the Wishart distribution can be challenging. To avoid this complexity, and to facilitate the transition from existing practices, the implementation described in Section 4 did not employ Gaussian distribution and Bayesian updating.

3.2. Risk Assessment

In general, the risk of a decision rule is obtained as an expectation of a loss function [12]. When data are not available, the risk reduces to the loss function. In the proposed framework, risk r is estimated as a nonlinear mapping, where the domain is spanned by the shipment priority score $s_{ps}$ and the subjective assessment of likelihood $p_{SAL}$.

$$r=L(s_{ps},p_{SAL})$$

(10)

An example mapping, in the form of a look-up table, is defined in

Table 3. Risk assessment table $L(s_{ps},p_{SAL})$.

		Subjective Assessment of Likelihood ${\mathit{p}}_{\mathit{SAL}}$
		Informational	Possible	Likely	Very Likely	Imminent
		0–0.3	0.3–0.5	0.5–0.8	0.8–0.95	0.95–1.0
SPS$s_{ps}$	0.8−1.0	0	0.5	0.8	1	1
	0.6−0.8	0	0.3	0.5	0.7	0.9
	0.4−0.6	0	0.1	0.3	0.4	0.5
	0.0−0.4	0	0.0	0.1	0.3	0.4

and illustrated in Figure 3.

Within this specification, the lowest range of SAL $p_{SAL}\in [0,0.3]$ corresponded to zero risk, while the lowest range SPS was associated with non-zero risk when SAL was high. As stated above, the specification of Table 3 was based on the user’s preferences; different users may perceive risk differently.

Finally, the estimated risk r is compared to a user-defined, acceptable threshold ${\theta }_r$: shipments with $r>{\theta }_r$ were recommended formitigation, as expressed by the mitigation indicator $I_m$

$$I_m(r,{\theta }_r)=\left\{\begin{array}{cc}True,\hfill & r>{\theta }_r\hfill \\ False,\hfill & r<{\theta }_r\hfill \end{array}\right..$$

(11)

The risk computation is summarized in Algorithm 1. The input data consists of the set of all shipments scheduled for the time interval of interest $\left\{\mathcal{S}\right\}$, normalized customer variables $c_v$ with associated weights $w_i$, geofenced area specified by ellipse parameters (center coordinates $({\lambda }_c,{\phi }_c)$, semiaxes a and b, and tilt angle $\theta$), SAL $p_{SAL}$, and the risk threshold ${\theta }_r$. The algorithm employs internal normalization for customer variables. After the normalization, it identifies affected shipments $\left\{\mathfrak{S}\right\}$ that originate or terminate in the geofenced area specified by the ellipse. For each shipment, first calculate the SPS, then risk from the nonlinear mapping, and finally the mitigation indicator function. The output of the algorithm is a set of ordered pairs of mitigation indicators and their associated risks $\left\{(I_{m_i},r_i)\right\}$.

Algorithm 1: Risk calculation.

4. Implementation

Dow is a very large global manufacturing company that conducts business in more than 160 countries. Dow’s supply chain utilizes a variety of modes of transportation such as: Air, Deep Sea, Inland Waterways, Pipeline, Postal Service, Rail, Road, and Sea [13]. Dow is keenly aware of the ramifications that disruptive events have on its operations, its customers, and its overall profitability. In an effort to advance its existing supply chain event management processes, Dow (and partner organizations) proposed a research project to the Manufacturing x Digital (MxD) Institute (www.mxdusa.org) aimed at improving and further automating the current SCEM process underway at Dow by creating a framework to digitize, integrate, and automate the information pipeline and action workflow, along with offering Dow users recommendations based on prior mitigation actions [13]. The MxD Institute awarded project resulted in the development of five (5) modules that perform independent actions, but when linked together, deliver the desired results applied to outbound Dow shipments. The five modules are as follows:

• Predictive Transit: This module provides an estimated shipment transit time for future shipments based on source, destination, planned shipment date, product type, weather, and event data.
• Risk Assessment: This module provides a graphical user interface (GUI) to enable a user to document current and future events and automatically compute a risk for each individual outbound shipment in the affected geographical area.
• Mitigation Planning: This module automatically sends a communication (text/SMS or email) to subscribed decision makers when an outbound shipment has been promoted by the RA module. The communication provides an overview of the shipment and the event impacting it. The user can then enter in mitigation information, which is stored. After enough mitigation decisions are collected, a machine learning method may be trained to then automate recommended mitigation actions.
• SIMBA Chain Communications: This module integrates relevant data from different modules using a blockchain ledger and sends automated notifications to targeted individuals (Dow internal and external) when risk thresholds are met.
• Performance Analytics: This module is a data enablement SQL table within the Microsoft Azure environment with direct connection to a dashboard that calculates and displays Key Performance Indicators (KPIs) which are derived from the various modules. This module provides aggregated data, along with an easy access point for monitoring and decision making.

Figure 4 depicts interactions among the modules.The focus of this article is the RA module, which received information from users directly (SCEM analysts and business unit managers); read additional information from decision-support data and the predictive transit module; and finally stored the information to Risk Mitigation/Performance database and sent an immutable record to the blockchain. Dow’s expected value from such a system as a result of reductions in disruption incurred freight costs and reductions in disruption related manpower costs is estimated to be 5,000,000 USD over three years in Dow’s Outbound Logistics space for North America [13]. Although the modules described above were developed to be independent, each module was designed with interfaces to pass data to other modules as needed. For example, the RA module can read inputs from the Predictive Transit module, or directly from a human (supply chain event manager). And under the circumstance where the RA module informs the Mitigation Planning module regarding a specific shipment, the RA module and the subsequent modules all coordinate. The implementation of the described methodology for the RA module is depicted in the block diagram of Figure 5.

For all shipments originating or terminating in the event-affected area, SPS $s_{ps}$, computed from weighted customer variables, and SAL $p_{SAL}$, provided by the SCEM analyst, were mapped through a utility function to produce risk r, which was compared to the acceptable threshold ${\theta }_r$. A shipment with $r>{\theta }_r$ was recommended for mitigation. The RA framework is accessed through a GUI, which connects to the manufacturer’s database and is further described in the Code and Implementation section as well as in the Appendix A. The additional figures in the Appendix A describe how to use the GUI and gives an example of a multi-day geofence. For an event spanning multiple days whose geofences enclose hundreds of shipments, the entire risk assessment computation, including database communication, takes about 20 seconds.

Events with fewer affected shipments complete the risk assessment in less time. In general, an individual shipment’s processing takes a fraction of a second. This includes obtaining geo-location of the shipment, querying associated customer and business unit variables, the entire risk computation, database updates, and GUI updates.

4.1. RA Database Implementation

The database was designed to connect directly to the manufacturer’s shipment data. Data on shipments are queried from the manufacturer’s tables, and the resulting event generation is saved into the RA module’s database, described next. There are several tables in the RA database and they deal with event details, geo-spatial coordinates, risk mapping, business unit weightings, and customer variables. Figure 6 shows the 11 tables used in this implementation.

This implementation featured five customer variables used in determining SPS: Customer_Segmentation_CV, Customer_Contract_Demand_CV, Customer_Distinction_CV, Customer_Rating_CV, and Customer_Margin_CV. Each variable had an associated table with two fields, one for the category or interval that the customer belonged to in that variable, and the other was a value associated with that category or interval, which would be used in normalizing customer variables for the SPS. For example, if the variable was Customer_Segmentation_CV and it contained five levels, each with a name and a relative importance value, then the specific customer associated with the current event’s shipment would have the category and value associated with the variable.

The event tables allowed a user to bring back previous events for updates, or to check on potential changes. If the RA software has been used previously, the first query is sent when the GUI is started, and a table is populated with previous events, from these tables, that the user can select and show on the map. These were events that were previously saved into the events tables. If an SCEM analyst decides to change the settings of a previous event they can choose it here, make the changes, and submit it as an updated event. They are described as follows:

• Events table (top left) contained a unique event ID, date range, event status and category, shipment mode, and some information on whom recorded the event and where, such as event manager, region, updated on, updated number, and finally some user comments if desired.
• Event_Geofence table recorded unique event information, viz. event ID, update number, day in event, as well as the event data and parameters of the geofence: longitude, latitude, A (major axis value), B (minor axis value), and tilt.
• Event_Shipments contained information on the populated shipments from the manufacturer’s database as well as user supplied information for the given event. This table contained four fields that labeled a unique shipment within an event. These were event ID, day in event, shipment ID, and update number. The shipment mode was captured just as it was in the Events table. A column for status was added for tracking in-progress and updated events. SAL and SPS are calculated per shipment per event in order to obtain a mitigation indicator $I_m$ for each shipment, for each event. A comments field was included for user comments, and finally, two additional columns named Human SPS and Human Risk Score were added so a business unit manager could enter their own interpretation of shipment priority and risk to the event.

4.2. Code and Interface

Code was developed using Python [14] in a Jupyter Notebook scientific computational environment [15]. The software used to generate interactive maps in which the SCEM analyst would place geofences and observe shipments was implemented using IPyLeaflet [16], a bridge between Jupyter and the Leaflet [17] mapping library. The module was deployed in Microsoft Azure environment, which served as an integration platform with other modules briefly described above. At the time of the first implementation Jupyter Notebooks in Microsoft Azure could only be set to be either entirely open, or for a single-user. It was not possible to set a notebook to be private and shared by a dedicated team. To overcome this limitation, we deployed the notebooks using Jupyter Hub, which was pre-loaded in Microsoft Azure Ubuntu virtual machine. Then we managed users via the virtual machine. The RA module was contained in a single Python (.py) file and was run by instantiating the module in a Jupyter Notebook. This approach was taken so that the code would not distract the users, and also to protect the code from unintentional modifications. The module contained three classes, which are described in the following section.

The first and simplest class in the module is the database class. It is used to connect and communicate with the manufacturer’s database. It is small and only contains an initialization method for connection, and a simple query method which runs a query and returns all results as an array. There are no parameters to this module. It is called in the initialization method of the event creation class, the second and main class of the module. The event creation class contains all the methods for interacting with the GUI (Figure 7), retrieving and displaying information requested by the analyst, setting off the risk score computation, saving the data to the database, and submitting events to the database, Simba Chain, and mitigation processes.

When the user selects the option to add a geofence to the map, the third class, the geofence class, is used. This class is used to generate an elliptical geofence in the form required for IPyLeaflet to display. The ellipse is made out of 80 points, which are generated from the ellipse equation, which is defined using a center, major and minor axis, and tilt values. These are set by the user when interacting directly with the geofence on the map. Another way the geofence is created is by the selection of a previous event, which uses the stored parameters from past events to generate a geofence for each day in the event and displays them on the map. The RA module was developed in Microsoft Azure and tested using Jupyter Hub [18].

4.3. Users

The four types of stakeholders in the RA module are the SCEM analyst, the system administrator, the business unit manager, and the software developer. The relationship between the module and these four stakeholders is described in turn.

The SCEM analyst would use the interface to manage events: draw the geofence, select type of shipment (road, rail, or both), and assign SAL. The analyst can also update the information related to existing events. They may wish to return to a previous event after new information is learned, and change the GUI values for risk assessment. For example, environmental or social changes may require the geofence locations to be moved. This could relieve certain shipments no longer in the affected area from mitigation and capture new affected shipments that were not part of the original event.

The system administrator sets up the module for additional users, installs software in a new environment and manages permission on the network the RA module is running on, such as database access.

Business unit managers can overwrite the final risk score, or its intermediate results. These are stored in the database and are initially empty rows. The results of the risk score calculation are stored in a table. Additional empty columns have been added for the business unit managers to enter their personal scores by hand. In this module, the two available columns are Human SPS, and overall Human Risk Score. They may wish to return to a previous event after new information is learned, to update the database. These data entries will become increasingly valuable over time as new disruptions in supply chain events lead to different mitigation options. The potential for data-driven learning in future implementations was considered when designing the framework in this way.

Finally, a software developer can reuse, modify, and/or extend the capability of the code.

5. Conclusions

A framework for risk assessment of potentially disruptive events, developed to facilitate a smooth transition from the existing, manual processes towards automation, was introduced. The initial implementation strongly depended on human participation: SCEM analyst provided input probability—SAL, humans also had capability to overwrite the model-estimated relative shipment importance—SPS, and even overall risk. Because the key inputs depended on people, probabilistic models were kept simple, to make the usage more efficient and avoid overwhelming the user.

The framework was illustrated in the Dow case study and implemented in the Jupyter scientific computational environment. MS SQL database tables stored the shipment data, model parameters, event-characterization parameters, and model results. The framework featured the data collection system designed for capturing human decisions that were difficult to articulate, paving the way to the ground truth dataset that will enable future machine learning solutions. In early tests, the initial semi-automated solution suggested great acceleration of the decision making process compared to the traditional manual process, from hours down to seconds.

The framework was designed to be used for outbound shipments in a business-to-business environment. These shipments can include several different types of modes, including air, ship, road, rail (and combinations, i.e., mixed-modes of transport), and can include both domestic and international routes. The intent of the project was to be able to use information that informs the likelihood of an event that could have an impact on outbound shipments, and then develop a decision support platform that allows business personnel to take appropriate actions to mitigate disruption to the manufacturer and/or its customers. Although this use case is fairly broad, the framework can not be applied to all types of transportation problems. Applications where expected transportation time is minutes (e.g., food delivery) would not be a suitable application since it would be unlikely that there would be enough time to determine and implement mitigation actions; however, it does seem likely that the framework could be applied to inbound shipments, as long as accurate data could be obtained regarding planned routes, in transit location, and other relevant data to implement the RA framework. One limitation is that the only uncertainty is related to weather, or similar event; the present framework does not include many other aspects of inbound logistics, such as operations of the suppliers and their dependencies.

Future work will examine the extension to develop additional aspects of inbound logistics. More work is needed in developing the cost models, which will pave the way to more traditional optimization. The next iteration of the implementation will test users’ adoption of the second interpretation of the geo-fence ellipses, as a Gaussian distribution as well as the mixture of Gaussian distributions. Finally, the captured human decisions that disagreed with automated assessments related to SPS, or overall risk, will be used to develop a better data-driven model over time.