The Pennsylvania State University
The Graduate School
Harold and Inge Marcus Department of Industrial and Manufacturing Engineering
AN APPLICATION OF A THESAURUS PROCESS MODEL TO HUMAN RESOURCE
BUSINESS PROCESS MODELING
A Thesis in
Industrial Engineering
by
Taiwo O. Odewade
 2013 Taiwo O. Odewade
Submitted in Partial Fulfillment
of the Requirements
for the Degree of
Master of Science
May 2013
The thesis of Taiwo O. Odewade was reviewed and approved* by the following:
Soundar Kumara
Allen E., & Allen, M., Pearce Professor of Industrial and Manufacturing
Engineering
Professor of Computer Science and Engineering
Thesis Co-Advisor
E. Christopher Byrne
Assistant Professor of Mathematics and Research Associate ARL
Thesis Co-advisor
Paul M. Griffin
Professor of Industrial and Manufacturing Engineering
Head of the Department of Industrial and Manufacturing Engineering
*Signatures are on file in the Graduate School
iii
ABSTRACT
Organizations are increasingly using Business Process Models (BPMs). However, these
models have two major drawbacks. First, the BPMs, mostly are in a non-machine-readable
format, which makes them inaccessible to machine learning and intelligent queries. Secondly,
semantic heterogeneity, by which we mean the inconsistency in vocabulary and other language
usage across organizational personnel, leads to inconsistency in interpretation of models. Past
approaches to eliminate semantic heterogeneity include the enforcement an official
“standardized” vocabulary and even defining entire modeling languages, but history has shown
enterprise-wide vocabulary enforcement is expensive at best and often infeasible. ‘Semantic
Business Process Modeling’ (SBPM) purports to resolve semantic heterogeneity without relying
on language standardization, by instead relying on users’ a priori knowledge of the business
processes to support
correct, consistent interpretation of models.
This strong assumption
imposes severe limitations on the applicability of these models.
This thesis demonstrates any business process can be modeled using a thesaurus that is
machine-readable to support software applications and mitigates semantic heterogeneity by
explicitly mapping it.
With this approach, we posit that specialized technical skills will not be needed to
interpret the process model, allowing organizations to implement the models minimal user
training. The interactive query capability provided by the thesaurus structure, and supported by
numerous commercial software packages for thesaurus maintenance and creation, eliminates or
reduces the need for any assumptions on a priori user knowledge. The Thesaurus Business
Process Model (TBPM) we propose in this work is compliant with the ISO 9001(Quality
Management Systems) standard, which is used as a benchmark in most organizations in
iv
improving the management of information flow. Thesauri have been written about in context of
linguistic and database design search engines, where semantic heterogeneity is a natural
phenomenon, but never in the process modeling literature, which also requires mitigation of
semantic heterogeneity.
To validate the claims, this thesis includes TBPM of the United States Marine Corps’
(USMC) human resource development process (HRDP). The USMC HRDP model is interactive
to improve collaboration among specialized sub units. In addition, it also provides necessary
information to fully integrate the HRDP management with agencies external to the management
process. This thesis concludes with ideas for going beyond resolution of semantic heterogeneity
to resolution of heterogeneity of model structure across all types of BPMs.
v
TABLE OF CONTENTS
LIST OF FIGURES ................................................................................................................. vii
LIST OF TABLES ................................................................................................................... ix
Chapter 1 Introduction ............................................................................................................ 1
1.1 Motivation ................................................................................................................. 3
1.2 Problem Description ................................................................................................. 4
1.3 Uniqueness and Contributions .................................................................................. 6
1.4 Thesis Organization ................................................................................................... 6
Chapter 2 Framework and Literature Review ......................................................................... 7
2.1 Business Process Model ............................................................................................ 7
2.2 Process Modeling Literature Review ......................................................................... 9
2.2.1 Flow Chart ....................................................................................................... 11
2.2.2 UML 2.0 Activity Diagram (AD).................................................................... 11
2.2.3 Colored Petri-Net (CPN) ................................................................................. 12
2.2.4 Role Activity Diagram (RAD) ........................................................................ 13
2.2.5 Data Flow Diagram (DFD) ............................................................................. 13
2.2.6 The Integrated Definition for Function Modeling (IDEF) .............................. 14
2.3 Process Model Structure ............................................................................................ 14
2.4 Semantic heterogeneity .............................................................................................. 17
Chapter 3 Research Methodology ........................................................................................... 19
3.1 Introduction ................................................................................................................ 19
3.2 Thesaurus BPM (TBPM) ........................................................................................... 20
3.2.1 Example of a BPM .......................................................................................... 22
3.3 Methodology .............................................................................................................. 24
3.3.1 Outline the representational requirements and logical framework of a
process model ................................................................................................... 24
3.3.2 Mathematical structure of a thesaurus business process model ...................... 28
3.3.3 Formulate the process space of a process model as a thesaurus...................... 29
3.3.4 Manipulation and transformation of the process space ................................... 30
3.3.5 Result and analysis procedure ......................................................................... 31
Chapter 4 Application ............................................................................................................. 33
4.1 Introduction ................................................................................................................ 33
4.2 Current process map of the MPP ............................................................................... 34
4.2.1 Use of the Thesaurus terminology standard library ........................................ 36
4.2.2 Explicit differentiation between sub-processes and data entry ....................... 39
vi
4.2.3 Employing the use of data analysis on data entry ........................................... 45
4.3 Framework of the Thesaurus Process Space .............................................................. 52
4.3.1 Software Implementation and Browser GUI ................................................... 57
4.3.2 Server Interface ............................................................................................... 57
4.3.3 Call level Interface .......................................................................................... 57
4.3.4 Process Model GUI ......................................................................................... 58
4.4 Proposed Framework Example Implementation ........................................................ 61
Chapter 5 Validation ............................................................................................................... 64
5.1 Validation ................................................................................................................... 64
Chapter 6 Conclusion and Future Work ................................................................................. 67
6.1 Conclusion ................................................................................................................. 67
6.2 Future Work ............................................................................................................... 68
Appendix A Terminology and Relations Tables..................................................................... 71
Reference ................................................................................................................................. 112
vii
LIST OF FIGURES
Figure 1: Manufacturing and vendor inquiry process. ............................................................. 2
Figure 2: The Principal approach of the BPM. ....................................................................... 3
Figure 3: Expense request payment business process model. .................................................. 17
Figure 4: Expense payment request business process model. ................................................. 23
Figure 5: Expense request payment thesaurus business process model. .................................. 23
Figure 6: Concepts relations graphical representations. ......................................................... 27
Figure 7: Shows the process instance map of Manning control for forecasting enlisted
accessions training. . ....................................................................................................... 34
Figure 8: Shows the process instance map of Manning control for forecasting officer
accessions training. . ....................................................................................................... 35
Figure 9: Shows the use of the terminology standard for the forecasting enlisted
accessions training. . ....................................................................................................... 37
Figure 10: Shows the use of the terminology standard for the forecasting officer
accessions training.. ......................................................................................................... 38
Figure 11: Shows the use of the Business Process Owner and Has Child Process
terminology standards.. .................................................................................................... 39
Figure 12: Shows the use of input terminology relationships in forecasting enlisted
accessions training.. ......................................................................................................... 41
Figure 13: Shows the use of input terminology relationships in forecasting Officer
Accessions training.. ........................................................................................................ 42
Figure 14: shows the input sub-process that can be used in both the officer and enlisted
accession management.. ................................................................................................... 44
Figure 15: Depicts the relationship between a sub-Process and the data entry ..................... 45
Figure 16 Organization structure of enlisted marine population per MOS. ............................. 46
Figure 17: Shows a sample graph of the maximization of the employment quality. .............. 50
Figure 18: Perpetual management control cycle. .................................................................... 51
viii
Figure 19: This figure illustrates the process space among sub-processes in the MP
process model................................................................................................................... 54
Figure 20: This figure illustrates what makes up the process model sub-process space.. ...... 56
Figure 21: Shows the terms listed alphabetically on the main screen of the TBPM............... 59
Figure 22: Shows the second screen produces when a term is clicked. .................................. 60
Figure 23: Shows the overview of the ISO 9001:2008 process approach requirement. ......... 66
ix
LIST OF TABLES
Table 1: Manufacturing and vendor similar tasks................................................................... 2
Table 2: BPMN language core modeling elements. ............................................................... 15
Table 3: Context of the attributes............................................................................................. 21
Table 4: ISO standard used for the construction of the process model. .................................. 25
Table 5: Forces affecting the MPP........................................................................................... 48
Table 6: Shows the attributes of the sub-process space. ......................................................... 55
Table 7: Process model call level interface.............................................................................. 58
Table 8: ISO 9001 and TBPM Key Process Space Management Requirement check list. .... 65
Table 9: Shows the MM Recruit Distribution process space.. ................................................ 71
Table 10: Shows the MM Enlisted staffing process space...................................................... 74
Table 11: Shows the MM Officer Staffing process space....................................................... 79
Table 12: Shows the Partners & Common Processes process space....................................... 84
Table 13: Shows the MP Manning Control process space...................................................... 88
Table 14: Shows the MP Target Force process space.. ........................................................... 90
Table 15: hows the MP Officer Inventory Plan process space.. ............................................. 92
Table 16: Shows the MP Enlisted Inventory Plan process space............................................ 101
Chapter 1
Introduction
In most organizations, business process models are used to automate workflow related
tasks and to provide a platform to query the process space. However, business process models
(BPMs) can be modeled in different ways in the same organization. Thus, the issue of continual
bi-directional translation or semantic heterogeneity among business process models (BPM)
emerges. In the current age, different groups in an organization are remotely as well as
automatically trying to solve problems related to various tasks from finance to customer relations.
It is a common practice in organizations to refer to the same business task or subtask in different
groups of an organization.
In an organization, such as a manufacturing company, parts used in the manufacturing
processes are coordinated with individual vendors in order to make the parts readily available.
Both manufacturing and vendors can have a model representation of the process showing the
workflow of the parts. Manufacturing for example may have a generic workflow BPM while the
vendor may have its own BPM for the same task.
Therefore, the two units, manufacturing and vendors, should clearly be able to understand
what information needs to be communicated and how it needs to be communicated to ensure the
minimization of error in accomplishing the task. For example, Figure 1 depicts a (simplified)
manufacturing and vendor’s business process view of the organizations task. In both processes,
“vendors inquire about parts” are utilized. However, the events are treated different in both
organizations. Table 1 illustrates terms that refers to the same task in both organizations but
treated differently due to lack of understanding of each other’s organizational process. This forms
the motivation of my thesis.
2
Table 1: Manufacturing and vendor similar tasks
Manufacturing
Vendor
Vendor inquiries about parts
Vendor inquiries about parts
Accounting inquiry query processing
Accounting inquiry query processing
Generate quotation Inquiry
Complete quotation Inquiry
Figure 1: Manufacturing and vendor inquiry process
Though in the two models, “generate quotation Inquiry” and “complete quotation Inquiry,”
represent the same task, due to the labels (terms) used, these two can be thought of as being
distinct. This is due mainly to, the use of domain specific terminologies and interfaces by
different organization as a means of improving high fidelity words which indirectly makes their
models incomparable. Therefore, it becomes necessary to resolve the issue of semantic
heterogeneity as a means of improving communications between BPM across the organization.
3
1.1 Motivation
It has becomes necessary to semi-automate the bi-directional translation among BPM with
domain specific terminologies as a means of resolving the issue of semantic heterogeneity and
improving the information retrieval system performance. This forms the motivation of the current
thesis. The main idea of the thesis is to combine a semantic framework, BPM methodology and
the thesaurus terminology structure in automating the mediation of various process spaces in an
organization repository. The fundamental approach of resolving the issue of semantic
heterogeneity is, finding a one-to-one similarity between terms used in describing the activities
among the process spaces of an organization repository. The approach use in this thesis is
representing the process space of a BPM using a thesaurus as a means of allowing machine
reasoning for bi-directional translation between BPM. Figure 2 shows the principal overview of
the BPM.
Figure 2: The Principal approach of the BPM
4
The assumption made in this thesis is that there is only a one-to-one mapping between
process model elements. The assumption is made in order to prevent possible process element
relationship mapping explosion. Thus, preventing a computational intractability of the algorithm
used for computing the similarity metrics between process elements in a model.
1.1 Problem Description
Nowadays, many enterprises and organizations employ information systems to support the
execution of their business processes. Examples of such information systems used include
Enterprise resource planning (ERP), Customer relationship management (CRP) or Workflow
Management Systems. These processes are readily available across the enterprise in order to
facilitate collaboration across organizational boundaries in performing common tasks. However,
different organizations in the enterprise may use specific vocabulary, terminologies or structural
representations for modeling their business processes. Therefore, the issue of semantic
heterogeneity arises. A brief description of semantic heterogeneity in process modeling is as
follows: Although the process space of an organization is well documented in a computer system
(e.g. stored in a process model form, fragments of code, data structure, etc.), an expert is required
in order to query and manipulate the process space regularly. For example, when a list of
resources or events that meet a required definition is needed, business analysts have to compose
such results manually, which Is time consuming, costly and error prone. This makes it difficult to
compare business processes across the organizations. Due to the fact that, BPM’s can be
represented using the same modeling language in different ways in the same organization it
becomes important to structure the process space of the BPM. The primary issue in business
process management is mediating semantic heterogeneity among business processes. Semantic
heterogeneity is caused by the variations of the manner in which information is structured in a
5
business process. This also makes it difficult for a business process to share information even
when they have similar processes. Thus, the main objective is allowing business processes to
retain domain specific terminologies and interfaces and still facilitate information sharing.
According to [1], as an organization grows, the number of business processes grows and therefore
the number of shared business processes also grows. An appropriate technique for resolving the
issue of semantic heterogeneity among business process models caused by using different
abstraction levels for process element terminology is by using a semantic business process model
SBPM framework [2]. An SBPM is used to help resolve the issue of business process
interoperability and interconnectivity across the enterprise.
The SBPM approach developed for the business process model is based on measuring the
degree of similarity of elements within different models by using an automated domain specific
semantics metric based on an adaptive thesaurus from [3] used in order to retrieve only the
semantic information contained within the models.
Resolving the issue of semantic heterogeneity involves measuring the degree of semantic
similarity between process (search) models. In summary, semantic similarity is defined from
various prospective, which are mostly broken down into three groups:
•
Similarity between texts: This is based on the comparing of labels that appear among
business process models (activity labels, event labels, gateway labels, etc.).
•
Similarity between structures: This is based on observing that the business process model
has a graphical topology. This could also take into account similarity between texts.
•
Similarity between behaviors: This is based on comparing the behavior of two elements
in a business process model when a task is executed.
Unfortunately, it has been shown in a series literature surveys that measuring the degree of
similarity process modeling techniques have various downfalls when assessed in light of its
6
compliance to ontological and terminological principles [5, 6, and 7]. The repercussion is that
most of the information used in the construction of the process models remains abstruse to both
human translators and software tools.
This thesis is composed of analyzing the compliance of the thesaurus process modeling
principles to well establish process modeling domain specific terminology principles and to
widely established ontology principles used in the classification and organization of vocabularies
in process modeling.
1.2 Uniqueness and Contributions
The contributions of this thesis are, (1) outline the semantic representation requirement of a
BPM’s process space, (2) represent the process space in the form that provides the tools necessary
for machine-accessible representation and manipulation of the process space of a BPM, (3)
describe the scope of the semantic transformation of a process model, and (5) explain the benefits
and drawbacks of using a thesaurus to semantically structuring the process space of a BPM.
1.3 Thesis Organization
In Chapter 2, the framework and literature is reviewed to summarize work done in process
modeling that is related to this thesis. The research methodology is described in Chapter 3, which
also includes examples and mathematical structure of a thesaurus business process model
(TBPM). In chapter 4, the TBPM was applied to the Marine Corps manpower process (MP) with
an example implementation of the framework. In Chapter 5, the TBPM was validated and
analyzed based on its compliance with the ISO 9001:2008 process approach requirement. Chapter
6 contains the conclusion and future work. Appendix A contains the terms and relationships table
of the entire human resource development processes (HRDP) process space.
7
Chapter 2
Framework and Literature Review
2.1 Business Process Model
A business process model (BPM) is a collection of logically related activities and task(s)
performed to accomplish an organizational goal. It is often visualized as sequential flowchart of
activities and task(s) with decisions being made at each process. Each of the activities or tasks
that need to be accomplished is denoted as an element in the business process model. There are
various process modeling languages found in literature that are used to adequately formulate the
process space of a process model. However, most modeling languages rely heavily on the
designers’ view of the model. Thus, the issue of semantic bottleneck arises. Semantic bottleneck
is when it becomes difficult to query and manipulate the BPM without the use of a human
mediator in facilitating the exchange of information. Process models are used mostly as a
knowledge base of logical information flow and viewed in order to retrieve information valuable
to the organization such as, what work needs to be done, who is in charge of doing the work, at
what time and location will it be done, what parts are needed and what is the final product.
The BPM framework consists of four different perspectives namely, functional
perspective, organizational perspective, behavioral perspective and informational perspective.
The four perspectives are used to ensure that all the fundamental building blocks of a process
model are taken into account.
Many modeling notations are available to capture the business processes such as, Petri
Nets, EEML (Extended Enterprise Modeling Language), UML Activity Diagram etc. However,
the modeling notations used as a bench mark to illustrate the functionality of a BPM in the thesis
is based on the business process modeling notation (BPMN) language from [4].The BPMN
language is used as a tool in order to define the behavior of an element in a business process. In
8
BPMN there are three core modeling elements: activity (‘a’), events (‘e’) and gateways (‘g’).The
manufacturing and vendor inquiry process in Figure 1 is an example of two business processes
using the BPMN language.
The BPM modeling nomenclature and attributes are similar to ontology in the way the
elements are used to illustrate the framework process models in literature. Thus, a process model
can be viewed has a structured list of terms with relations and definitions that constantly changes
based on the state of the model to provide a desired outcome for an organization. BPM are
created in most organizations as a software tool used in monitoring the state of the organization in
completing its desired objective. However, most process modeling tools have very limited degree
of mechanization because of the lack of uniform process model representation of the organization
at a semantic level. This in turn makes it difficult to generate an intelligent query and
interpretations of the process model search space. Thus, most process models have inadequate
machine accessible knowledge base and lack the ability to modify the process model without the
use of human intervention.
In this thesis we will prove that: (1) there is a need to unify the view of a process model
in a machine accessible representation form in order to allow the process model to be queried
using standardized expression consistent with business semantics (e.g. ISO 9001), (2) the process
space in most process models lack machine accessible representation at a semantic level, and (3)
machine accessible representation is a major advantage in mechanization (reduction in the use of
human intervention) of process models. Furthermore, we will show that (4) a thesaurus provides a
suitable machine accessible representation of the process model knowledge space. As an
outcome, we propose (5) a combination of a thesaurus and a BPM and develop a combined
process modeling technique called a Thesaurus Business Process Model (TBPM). The aim of the
9
TBPM is to support both the creation of process models and allow the process space to query able
by the use of logical expressions consistent with business semantics.
2.2 Process Modeling Literature Review
To further understand and study the behavior of a system, a process model is constructed
using a particular modeling language and sharing a particular viewpoint of the designer. Current
process modeling languages are not built on a descriptive logic-based process space
representation, and thus they are unsuccessful at making the entire process space of the process
model open to machine reasoning and querying. The lack of machine accessible representation of
the process space in the BPM causes difficulties when using it among various parties in an
organization. Thus, the following issues arise:
1. Process blindness: Occurs when it becomes difficult for business professionals and
managers in an organization to determine if a specific process is made up of existing
activities. Therefore, it becomes difficult querying the process space of the BPM by
using logical expressions. Thus, the problem of how to improve a process model by
checking the process practicability (e.g. before a new product is lunch) or process
space comparisons (e.g. The use of the International Organization for
Standardization for terminology principle) are done by professional analysts and not
by people who use the models.
2. Process goals and implementation complexity: There is no distinguishable separation
between the process goals and implementation specification which makes it complex
for managers in the organization to manage the process space of a BPM.
3. Modification requires professional experts: Modification of the process model
requires interaction between professional experts (e.g. IT personal) and business
10
experts. Therefore, the process is labor intensive which reduces the organizational
abilities of the organization.
4.
Manual development of process model: The development of the process model is
done manually according to the organizational need, which often requires numerous
organizational experts.
5. Process space definition and interpretation complexity: It is infeasible to utilize
machine reasoning in understanding the functionality of the basic activities in the
process space and how it affects the process model.
6. Complexity in B2B bi-directional Translation: It is difficult to collaborate among
businesses. At an initial glance at both process models the terminology may seem the
same, but after a deeper analysis they may turn out be different. Thus, there are no
standards in process modeling which allows for ambiguity in the interpretation of the
process space. For example, the word check semantically might mean a checkbook to
an accountant or a validation process for an engineer.
The aim of this section is to introduce various business processes modeling techniques
found in literature and also, to show how inefficient they are in representing the processes and
associated information. According to [8] a process is defined as “a structured, measured sets of
activities designed to produce a specific output for a particular customer or market.” There are
various definitions found in literature. However, they all have the same underlining meaning: a
process transforms a set of one or more inputs into a set of one or more outputs based on a
defined set of control measures. Some of the most widely used modeling techniques are reported
in the next section.
11
2.2.1 Flow Chart
Flow chart is one of the first modeling techniques used in modeling the business process.
The major advantage in using flowcharts is the ability to show the structure of the entire system.
A flow chart graphically represents the logical sequence of activities that needs to be
accomplished in order to accomplish the organizational goals.
The flow chart was created by computer scientists dating back to the 1960s [22], and was
intended to be used to represent the computer programming logic flow. However, due to the
generic nature of the techniques in capturing the sequential flow of information it has been
applied in various areas that involve the sequential flow of information. Despite being very easy
to use and interpret, flow charts are no longer considered a dominant process modeling technique
because they do not provide enough tools required to model a business process effectively. Thus,
flow charts are used as a simple high level graphical representation of how the elements in a
process model communicate and they are intended to be used as a narrative description of process
models when the true model becomes difficult to understand.
2.2.2 UML 2.0 Activity Diagram (AD)
The AD is considered as the standard in an object oriented process modeling (OO modeling)
technique. Based on [10], AD is effective in capturing the details in the design of a BPM in a
form that is suitable to translate to other programming languages. The AD technique serves as the
basis for representing other techniques because only common modeling construction and
notations are used in capturing the concepts of a model. The recent version of the AD [15] has 13
core modeling notations. However, the modeling notation can be further grouped into three
different categories:
12
•
Behavior diagram: describes the entire BPM functionality at a higher level of
abstraction
•
Interaction diagram: used to further visualize behavior diagram functionality of the
objects’ interactions
•
Structure diagrams: shows the static structure of the model by capturing the type and
instances of individual objects and the overall model application.
The uses of the various modeling notations can vary from a high level abstraction of the object
diagrams, depicting a relationship and interactions between business functions, to a lower level
object diagrams that illustrates the instances of an object and how their relationships impacts
other objects.
2.2.3 Colored Petri-Net (CPN)
The Colored Petri-net modeling technique is a graphical language used for constructing
and designing process models. CPNs are mainly used in cases where processes need to be
synchronized and communicated amongst them. CPN is an extension of the regular petri-nets
where different types of objects are depicted by different colors. The graphical representation of
the technique makes it easy to visualize the complex CPM model structure in order to understand
the interaction of individual processes. CPN integrates both hierarchical decomposition and data
structuring with the same quality as the regular petri-nets [13]. Furthermore, the hierarchical
decomposition of the CPN technique makes it easy to model large BPM using a set of separate
sub-process.
13
2.2.4 Role Activity Diagram (RAD)
The Role Activity Diagram technique is a high-level visual language used in capturing
the dynamics and structural role of a process model [13]. RAD has various BPM reported
applications found in literature ([16], [17], [18]), especially involving BPM with task like
applications. RAD is reasonably simple and intuitive to use and understand. It can be constructed
and interpreted by anyone with minimum prior knowledge about the technique. RAD is in fact an
object oriented modeling language and is based on the object state transition diagrams. The role
object describes how the state of an object changes states based on the interactions and actions
that occurred.
The major disadvantage of this technique is that processes are viewed as a sequence of
activities and cannot be decomposed into sub processes, making viewing the entire process space
difficult.
2.2.5 Data Flow Diagram (DFD)
A Data Flow Diagram technique is a graphical representation of a business process
diagram that shows the flow of information or data between activities [13]. The processes in the
model are represented from the data view point, i.e. it can be viewed as a way of data
organization from its original state. The “Action Diagram” is a unique case of the DFD with
much simpler notations and allows contextual analysis [13]. Thus, DFD is different from AD in
the sense that, it distinguishes between knowledge and information by showing both data and
material flows of data that concerns the performer.
14
2.2.6 The Integrated Definition for Function Modeling (IDEF)
The Integrated Definition for Function Modeling technique is a family of techniques that
are capable of addressing all the modeling requirements enterprise [13, 19]. An IDEF in the IDEF
family is chosen based on the user’s specifications. The most used versions of the IDEF’s are:
IDEF0, IDEF1, IDEF1X, IDEF2, IDEF3, IDEF4 and IDEF5. However, the only versions used in
constructing BPM are IDEF0 and IDEF1.
The modeling languages mentioned above cover the fundamental framework (functional
perspective, organizational perspective, behavioral perspective and informational perspective) of
building a process model [19]. However, querying of the process space is hampered by the
terminology used in the naming convention for the process element actions and the roles each
process element plays in the process model. These are attributes of natural language generally
added by the modeler. Thus, the identifiers used in modeling the process models are generally
ambiguous and confusing and leaves room for speculation for both human and machine
interpretation. Therefore, the semantics of the process element in a process model has to be well
defined in a machine accessible representation in order to facilitate intelligent queries and
machine reasoning.
2.3 Process Model Structure
In building a process model, the Business Process Modeling Notation (BPMN) language
based on generic modeling concepts was introduced in section 2.1. In BPMN graphical
specification, the notations are categorized into four sub categories [4]. These categories are flow
object, connecting object, swimlanes and artifacts. However, only the flow object and connecting
object define the control flow (behavioral) perspective of the process model.
15
Thus, in this thesis the BPMN language, process models are modeled using only two core
elements: flow objects (events, Activity and Gateway) and connecting objects (sequence flow,
message flow, and association). The flow objects and connecting objects are the core elements
used in describing the behavior of a business process. The flow objects and the connecting object
are defined in Table 2.
Element
Table 2: BPMN language core modeling elements
Flow Object
Description
Notation
Event
An event is an activity or task that will “occur”
during the course of a business process
Activity
An activity is a task that needs to be performed
in order to meet a specific goal.
Gateway
A gateway controls the branching and gathering
of the sequence flow of information. Thus, this
is used to determine the merging, branching,
forking and joining of parts.
Connecting Object
Element
Description
Sequence
Flow
The Sequence Flow shows the connection of two
or more flow object in the order in which it will
be performed.
Message
Flow
The message flow shows the flow of messages
between two participating connecting object that
are ready receive and send messages.
Associative
Flow
The Association flow is used to representing
information associated within flow objects. An
arrow head indicates the direction of flow.
Notation
The Flow objects consist of what action to perform, the order (parallel, sequential,
iteration) of elements that are involved in the decision process and the event generated at the
completion of the event. Connecting objects are lines connecting flow objects with each other,
16
with different kind of arrows representing the type of message and the relationship between the
flow objects.
Figure 3 shows a simple Expense Request Payment Business Process Model with eight
flow objects and nine connecting objects. The flow object can be further distinguished into
different types. However, they still share similar behavior and add no advantage to the BPM.
When abstracting a business process model as graph, a flow object can be represented as
a node and the connecting objects can be modeled as a vertex. Thus, the business process model
can be modeled as a graph of nodes and vertices. Furthermore, based on the BPMN graphical
representation of the business process model, the business process model has the following
properties:
•
It uses only core modeling elements namely, event, activity and gateway
•
There are no cycles and iterative processes are only supported through a blocked iteration
(e.g., through gateways)
•
A BPM has a single starting event and a single ending event.
Each BPMN element (flow object and connecting objects) has an attribute associated with it.
The attributes can vary from a set of values to a singular value of an element. The attribute of an
object will be retrieved using the attribute name and the name of the object in question. For
example in Figure 3, the cost attributes for node seven is: the account funds from each bank
account.
17
Figure 3: Expense request payment business process model
2.4 Semantic heterogeneity
Semantic heterogeneity in BPM’s is a phenomenon whereby Elements labels (term) has
disparities in the interpretation of the meaning of a term. This issue plays a major role in
facilitating collaborations across organizational boundaries in performing common tasks. The
major source of disparities in BPM is the use of different designers in the development of the
BPMs. Three kinds of semantic heterogeneity were identified: syntactic heterogeneity, linguistic
heterogeneity, and contextual heterogeneity.
Syntactic Heterogeneity occurs when two element labels have the same meaning but have
a slightly different spelling. For example, in one model the developer may use a label to “create
invoice” while in another may use “created invoice.” Thus, in Syntactic Heterogeneity only the
syntax of an elements label is considered.
Linguistic Heterogeneity is when BPM’s across the organization use different
terminology. The difference in an element name can be classified as: synonyms (the same
concept but different meaning). For example, a BPM might have an element identifier in one
18
model as “Employee Sex,” but in another model, the element identifier could be “Employee
Gender.”
Contextual heterogeneity is when not only the elements’ labels themselves are considered
in measuring the semantic similarity between terminologies , but when the context in which it is
used is also being considered. Thus, this similarity measure takes into account the elements that
precede and succeed the element. The similarity measure is essentially useful in situations where
an element label is used multiple times in the same BPM.
19
Chapter 3:
Research Methodology
3.1 Introduction
In essence, the major obstacle is semantically representing the process space of a process
model in order to provide scalable techniques and tools used for manipulation and representing a
machine accessible knowledge base. In order words, for the process space of a process model to
be machine accessible, each of the model elements (events, function, activities connectors, etc.)
have to be semantically represented and described during the creation of the model.
Consequently, in this thesis a combination of BPM and thesaurus is proposed to help tackle the
issue of semantic heterogeneity in process models. Thus, the combination yields an improved
process model called the Thesaurus Business Process Model (TBPM).
The TBPM covers the fundamental framework (functional perspective, organizational
perspective, behavioral perspective and informational perspective) and the semantic framework
of the process model. This will allow the process space to be machine-accessible and also allows
for machine-reasoning. Thus, the process space of a process model will be semantically annotated
or in a machine accessible representation that allows the software to propose new facts about the
processes with an underlying knowledge base. The approach of the TBPM is as follows:
1. Annotate individual process model element’s basic tasks and activities of a BPM
semantically using both the fundamental framework and a thesaurus;
2. Capture the landscape of the modeling language in a form that can be represented as a
thesaurus, because this will allow for model validation and evaluation;
3. Store the domain knowledge of the process model in an axiomatic form using natural
language rule formulation;
20
4.
Mapping of process elements from various process models into a virtual repository so
that the process space is retrievable to machine reasoning without the need for software
or business analysts;
5. Represent the process query space in an thesaurus query language;
6. Model the objective of the professional’s expertise as the goals of the process model, and
7. Use a thesaurus execution environment such as MultiTes PRO (thesaurus software
builder) in mediating the actual process space element and process queries space.
3.2. Thesaurus BPM (TBPM)
Thesauri are commonly used as linguistic references in retrieving specific relationships of
a specific vocabulary. It is used to annotate the knowledge base on an information source in order
to make it accessible to retrieve information based on the relations they have in common. A
thesaurus structures, organizes and preserves the knowledge space. It is assumed that the user of
the BPM has an adequate knowledge of how a thesaurus works. Also, the features of the
thesaurus will be introduced to the user with more extensive definitions in later sections. The
BPM thesaurus captures the relationships and meaning of each element in the model. The
relationships between each element are named to combat the issue of semantic heterogeneity in
the bi-directionality translation between asymmetric relations of element labels. Thus, the
relationship between elements’ terms can be written in the form element term 1 relation element
term 2. The International Standards Organization (ISO) [3, 9] is used as the standard to measure
the quality of the thesaurus process model. The thesaurus relationship used can be seen in Table 3
and were standard put forward by [4].
Based upon the attributes in [4] the relationships of a process model were defined in the
context of attributes by a tuple R=<I, IO, V, P > with
21
•
I = all instances of the specific attribute,
•
IO= all the input and output relationship of each attribute,
•
V= all values of each attribute
•
P= all properties of specific attribute
In Table 3 the list of all attribute relationships of a TBPM are given and organized by the
categories instances, IO sets, Value, and Properties which are part of the standard BPM attributes
relationship from [4]. The attributes relationships were chosen in order to allow the relationship
between terms to be automatically inferred and thus the TBPM designer does not have to
explicitly enter the information. This also allows the expansion of nominal compound
interpretation of terms between models which in turn increases the vocabulary of the combined
TBPM. Further interpretation of the topic introduced will be described in detail in the next
section.
Table 3: Context of the attributes.
Attributes
Instances
IO sets
Value
Property
Context
Has_Name
Has_Property
Has_Value
Has_Target
Has_Name
Has_Target
Has_Source
Produce_Output
Is_Outputed_by
Has_Name
Has_property
Has_Value
Has_Name
Has_sibling_Property
Has_value
22
3.2.1 Example of a BPM
Consider a typical expense payment request example in Figure 4: when the expense
payment request arrives in the organization, the accounting department checks to see what
account should be billed and then forward the information to the manager who enters the
information in the Petri-net software and then automatically updates his account information.
There the manager checks his inventory to make sure he has enough materials in his inventory
and either rejects the order or moves forward with it.
What does the expense process request model describe? A machine learning software
knows that there are eight process actions that need to take place before the goal of the process
model has been accomplished from the point of view of the accounting department. However, this
process model was made for the accounting department and shares only the terminology of the
accounting department. The manager might have a similar process model but, due to different
terminology, the processes are not compactable and the process space of both departments cannot
be queried by the other department.
A human is able to understand that “Prepare Check for ZNA bank” used in a similar
context is the same as “Develop ZNA bank billing data” but, matching reasoning can only use the
semantic information in the process space to make that conclusion. Thus, the thesaurus acts as a
mediator of heterogeneity of the process among various models. Figure 6 shows the expense
payment request model in a thesaurus representation. In the thesaurus process model an element
s labels will be modeled as a vocabulary. For example in Figure 4, the preparing check for ZNA
bank activity can be modeled as a node with a vocabulary preparing check for ZNA bank.
Therefore, the relationship between preparing a check for ZNA bank and selecting a bank based
on minimum transaction cost is: preparing a check for ZNA bank target is to select bank based on
23
minimum transaction cost, and vice versa select a bank based on minimum transaction source of
preparing a check for ZNA bank.
Figure 4: Expense payment request business process model.
Figure 5: Expense request payment thesaurus business process model
24
3.3 Methodology
The objective of this thesis is to develop models for the bi-directional translation between
(1) the business expert view of the enterprise process space and (2) the software experts’ (IT
personal) actual implementation of the process space. In many companies, process models are
mostly used for documentation purposes and are built by the process model software expert under
the guidance of the business expert. This process takes time and increases the chance of errors in
the models. In this thesis, we propose a novel approach based on using a thesaurus as a process
model which increases the level of automation between process models by bridging the gap
between software and business experts in an organization. A thesaurus can be used by anyone and
gives the business expert more freedom to add or remove data from the process space of the
process model. The major addition of the approach is the use of a thesaurus to mediate the two
viewpoints of a process models by automating or semi-automating the process space which in
turn facilitates machine reasoning. The methodology is broken down into four separate phases.
1. Outline the semantic representation requirement of a BPM’s process space,
2. Formulate the process space of a process model as a thesaurus,
3. Manipulation and transformation of the process space,
4. Result and analysis procedure of the semantic representation of the process space.
3.3.1 Outline the semantic representation requirement of a BPM’s process space,
The logical framework and design philosophy of the process modeling technique will be
designed using a thesaurus concept- centered design. The terminological principles of the process
space will be based on the standards produced by the International Standard Organization
(ISO).The ISO standards used are listed in Table 4 and will be further illustrated in Chapter 4.
25
Table 4: ISO standard used for the construction of the process model
ISO Standard
Title of ISO Standard
Number
ISO 704:2000
Terminology work -- Principles and methods
ISO 1087-1:2000
Terminology work -- Vocabulary -- Part 1: Theory and application
ISO 1087-2:2000
Terminology work -- Vocabulary -- Part 2: Computer applications
ISO 2788:1986
Documentation -- Guidelines for the establishment and development of
monolingual thesauri
ISO 16642:2003
Computer applications in terminology -- Terminological markup framework
ISO 9001:2008
Quality Management Systems
In this thesis, only the standard that we considered relevant and appropriate for process
modeling were considered and not everything contained in the standards were used. However, the
ISO 9001:2008 notations and standards were used as the cornerstone of the relations and terms
definition. The ISO is used in describing the relations between an object and its representation
using terminologies. The main objective of the ISO in process modeling is to establishment of
general principles that govern the definition and designation formulation, provide a common
language for effective communication between objects, and provide the tools necessary in
understanding the terminology objects and the context of use.
The ISO 9001:2008 Quality Management Systems (QMS) provides a set of principles
using a simple approach in the management of business activities in an effort to achieve a
consistent customer satisfaction. The ISO 9001:2008 standard requirements are set of
international management standards and guidelines that place an emphasis on the process
26
documentation, keeping of record, customer satisfaction and improvement of business process
also known as the process approach.
The process approach is a set of standards and guidelines promoted by the ISO and used
in the management and organization of a process model’s process space by creating a wellstructured knowledge based network of the interaction between processes. The objective of the
process approach is to enhance the effectiveness and efficiency of an organization in achieving its
defined goals. The process approach can be applied in the process modeling of major
management system that require process documentation, clarification and understanding of the
processes and its requirement.
The ISO process approach is a holistic processes modeling approach, compared to a
traditional approaches. It understands that while an organization is organized by fictional
department, generally using a hierarchical organization of relationships, the departments performs
their given task as a unit. Thus process approach is used to structure the process space of a
process model in order to better understand the interactions between different groups in an
organization.
The ISO has four fundamental content that are central to the terminology standard
namely, objects, concepts, designation, and definitions. The four fundamental concepts are
defined according to [ISO 9001:2008] as follows:
• Object: verbal designation of a general concept in a specific subject field [ISO
9001:2008].
• Concept: unit of knowledge created by a unique combination of characteristics [ISO
9001:2008].
• Definition (terms, names or symbols): representation of a concept by a descriptive
statement which serves to differentiate it from related concepts [ISO 9001:2008].
27
• Designations: Also known as, terms, names or symbols are used to represent a concept
[ISO 9001:2008].
In order words, the higher the concept system complexity, the easier it is in the
clarification of relations among various concepts. The concept relations are represented
graphically or formally as a list. However, graphical representations are more commonly used
and are depicted in Figure 7.
Figure 6: Concepts relations graphical representations.
As depicted in Figure 6, relations in the thesaurus process model will be organized into
three categories equivalence, hierarchical and associative relations, which are defined based on
the ISO standard definitions. The relations are formally defined using the reflexive, symmetric
28
and transitive abstract relations properties, in which the standard mathematical definitions and are
given below.
3.3.2 Mathematical structure of a thesaurus business process model
The use of a thesaurus for linguistic support for information retrieval was adopted from
[3]. The semantic distance between two terms in a process model will be calculated based on the
minimum number of terms between both vocabularies. Thus, each element in the process model
will be modeled has a weighted graph of relationships and terms. A thesaurus is defined in this
thesis as a pair of vocabulary “V” and relations “R” where, vocabulary is a set of one or more
terms and relations is a set of one or more relation. Therefore, the TBPM is defined as a weighted
graph of element labels, elements attributes or relations and element type or function. Thus, the
TBPM is a tuple (V, R, F, W) and is in one-to-one correspondence with the graph G = ∑ 𝐺 iwhere
Gi = (T, Ri) is the graph of Ri, for i = 1, . . ., k.The notation used to graphically illustrate a TBPM
is as follows.
•
T= (V, R, F, W): is a query able TBPM.
•
TA= (VA, RA, FA, WA): is a particular TBPM,
•
V= (V, R, F, W) is the non-empty sets of all element labels (nodes)
•
R ⊆ V X V is the set of set of directed elements attributes (edges)
•
F: [Activity, Event, Gateway, Sequence Flow, etc,] is the function that maps vocabulary
to Types
•
W is the weight associated with each elements attribute
•
SM(VA, VB): is the similarity between BPM TA and TB
•
SM(vA, vB): is the similarity between terms in BPM TA and TB
•
Source: R→ N returns the source vocabulary of the directed relationship
29
•
target: R→ N returns the target vocabulary of the directed relationship
•
type: V→ F returns the type of a vocabulary
•
type: R→ F returns the type of relations
•
attribute: R returns the attributes of the vocabulary

the number of incoming sequence flow

The number of instances to be created for an activity1

The node to be canceled for a canceled event.
TBPM can be seen from 4 different perspectives as mentioned in Chapter 2 however,
only the behavior prospective is taken into account.
Definition 1 (Semantic path metrics): The semantic path metrics is the number of common
terms in-between two terminologies. Let L (P) ∈ R+ be defined the length of the path
P={v1,v2,….vn} or the distance between two terms. The path length can be defined using
Minkowski Functional as L(P)=(∑𝑛𝑖=1 𝑊(𝑣𝑖, 𝑣𝑖 + 1)r)1/2, where r is an integer greater than zero.
Definition 2 (Semantic distance metrics): The semantic distance is the degree of closeness
between two terminologies in a process model. Thus, the semantic distance metric is the
minimum path length between two terminologies. Let vi and vj be two terminologies in the
process model, the semantic distance between them is defined as D(vi,vj) = min{ L(P)| P is the
path from vi to vj}.
3.3.3
Formulate the process space of a process model as a thesaurus
This phase involves formulating the process space as a thesaurus in the form that
provides the tools necessary for machine-accessible representation and manipulation the process
30
space of the process model. We propose a method that enhances the process space and is mainly
based on mapping the terms in the process models. Thus, we claim that mapping of terms and
relationship in the process space is essential to effectively manipulate the process space of a
process model. The terms are mapped to the thesaurus concepts which occur within the syntactic
unit boundaries. With the most used syntactic unit being the simple noun phrase. Underspecifying
the process space (i.e., identifying terms as a simple noun phrase) will be adequate enough in
mapping a process space to a thesaurus as opposed to, employing more elaborate ontology
analysis.
3.3.4 Manipulation and transformation of the process space
This phase involves manipulation of the process space which is the second most
important way of accessing information from the process space. This involves modification of an
existing process space, creating a new process space or combing multiple process spaces in order
to make data more machine readable. The functionality of the process space manipulation
requires similar representations as illustrated Section 3.2.2 and also includes the following
attributes, (1) being able to generate process space query into a thesaurus searchable format, (2)
the ability to resolve a given process space query into an organized format (e.g., thesaurus will be
distributed using OWL), and (3) create a thesaurus based process space engine that is capable of
executing the resulting organized data. Basically, most process modeling languages cover only
part of the requirement highlighted above which make them incapable of process space
manipulation. For instance, the orchestration of the process space of the BPMN language can be
defined which can allow one to query the process space without making any significant changes
to the model.
31
3.3.5 Result and analysis procedure
The use of MultiTes PRO together with the BPMN business process modeling software
tool will be analyzed in order to inspect the conformity of the thesaurus models in using the good
practices analogues with ontology and terminology design principles . Thus the thesaurus
representation will be analyzed based on its compliance with the ISO 9001:2008 terminology
standard and also on ontological principles found in literature. In order for a process model to be
ISO 9001:2008 compliant the process space has to clearly identify the key process management
requirements:
1. Identification of the key processes.
2. Identification of how the processes fit and impact each other.
3.
Assign the responsibility of managing the processes on a regular basis
4. Determine a criteria of measuring the performance of the processes based its process
objectives
5. Establish a procedure for controlling the processes and how they relate to the overall
objectives of the organization.
6. Identify the resources required in each processes and create a map of its process logic in
order to ensure its task are completed.
7. Determine a mode of communication in order to ensure everyone affected or perform
the processes understand the working of the processes
8. Ensure the objectives of the processes are being met by monitoring and assessing the
performance of the processes.
9. Identify what can be done to improve the overall performance of the processes based on
the key process measures.
32
Our objective is to show that a thesaurus process model meets the entire requirement of
the ISO 9001:2008 terminology standard and also the requirements of modeling space ontological
principles found in literature. Lastly, the benefits of employing the thesaurus in process modeling
will be analyzed in light of the goal of both process modeling technique and ontological
principles.
33
Chapter 4
Application
4.1 Introduction
The Marine Corps manpower process (MP) consists of Manning Controls, Target Force,
Officer Inventory Plan and Enlisted Inventory Plan business operations that are managed from a
technical perspective rather than from a business expert view. Each MP business operations are
broken down into various sub-divisions with each division working individually to complete their
assigned task in order to meet the overall objective of the MP business operation. The technique
used by the various sub-divisions is collecting the information needed from a previous division
and sending the final product to the preceding division without the need to document their
processes. Thus, each division is blindsided by previous and preceding divisions’ processes,
which makes changes at any level of the MP complicated. The major drawback of current
techniques used in describing the MP is the lack of machine-accessible data. The lack of
machine- accessible data is due to the following reasons:
1. There is no standard terminology in place to formalize the process space of the MP
2. Lack of documentation among various sub-processes of the MP, which makes it difficult
for sub-processes to understand each other
3. The documentation of the process space is in a non-machine-readable format, which
makes it difficult to query the process space
4. It is unsuccessful at making the entire process space of the MP accessible to machine
learning and intelligent queries
Thus, because the current techniques used are not built on expressive logic, many discussions
and human labor are required in order to accomplish the objective of the MP. In order to
accomplish the goal of the MP, a software tool capable of processing the MP requirement and
34
simple enough that anyone with a basic knowledge on how a thesaurus works can add or remove
data from the MP process space with minimum or no software programming skills.
4.2 Current process map of the MP
The MP is currently viewed as a chain of connecting sub-processes with data entry
passed down from lower sub-processes to higher sub-processes and requirements passed down
from higher sub-processes to lower sub-processes. Most documentation are done in house and
data entries are treated as sub-processes as opposed to instances of the entity. An example of the
current process map of the MP business operation units of the Manning control can be seen in
Figures 7 and 8.
Figure 7: Shows the process instance map of Manning control for forecasting enlisted accessions
training.
35
Figure 8: Shows the process instance map of Manning control for forecasting officer accessions
training.
In both the maps, data entries are viewed by the users as sub-processes of the Manning
Control business operations as opposed to data that needs to be collected and evaluated by the
Manning Control sub-processes in order to evaluate the future time horizon accessions
requirements based on the time horizon accessions and attrition rates. The data entry in Figure 7
and Figure 9 share similar sup-process with different data source. Thus, it very easy to confuse
the instances of sub-processes in the forecasting of officers and forecasting of enlisted Marine
36
sub-process. Based on both the figures there are three basic issues that needs be resolved in order
to make the process space of the MP machine accessible are:
1. Use of the Thesaurus terminology standard library,
2. Explicit differentiation between sub-processes and data entry, and
3. Employing the use of data analysis on data entry.
4.2.1 Use of the Thesaurus terminology standard library
Constructing a functioning MP process model is analogous to assembling a car, each part
is generally manufactured by different suppliers. However, when they come together they have to
fit in place perfectly in order to meet the manufacturing specifications. Each MP business
operations should be able to create a business process model and add it to the process model
repository using the thesaurus terminology standard library.
Standardization of terminology is a well-known method used in order to understand how
sub-processes corresponded to another as explained in Chapter 3. Thus, it helps by clarifying the
relationship between two connecting sub-processes. For example, if the original forecasting
officer accessions training and forecasting enlisted accessions training processes from Figures 7
and 8 were standardized using the thesaurus terminology standards library from Table 3, the issue
of semantic ambiguity will be resolved which will make it easier to understand the process space
map.
37
Figure 9: Shows the use of the terminology standard for the forecasting enlisted accessions
training.
38
Figure 10: Shows the use of the terminology standard for the forecasting officer accessions
training.
In employing the new thesaurus terminology standard on the MP process model, relations
such as “Has Child_Process” with dual “Has_Parent_Process,” are used to describe the
relationship between two terms in order to facilitate the reduction of ambiguity between terms.
For example, the relationship between Manpower Planning and Manning Control can be written
as Manpower Planning Has_Child_Preocess Manning Control or Manning Control
Has_Parent_Process Manpower Planning. More importantly, Manning Control is owned by MPP50(Manpower Plans and Policy, Integration and Analysis). Therefore, the relationship between
39
Manning Control and MPP-50 can be written as Manning Control Bussiness_Process_owner
MPP-50 or MPP-50 owned by Manning Control as shown in Figure 11. Thus, the issue of
relationship ambiguity will be resolved or reduced significantly if the relationship between two
terms can be better explained by introducing the appropriate thesaurus terminology standards in
the MP. Thus, anyone with a basic understanding of how a thesaurus works and how the MP
business operations functions will be able to understanding the MP process and how it may affect
its sub-division.
Figure 11: Shows the use of the Business Process Owner and Has Child Process terminology
standards.
4.2.2 Explicit differentiation between sub-processes and data entry
The data collected by the lower sub-processes are used to make a recommendation on
future planning horizons. The information collected is usually in the form of numbers. For
40
example, the officer forecasting sub-process may need to know the average number of accessed
officers in a particular MOS in the past 3 years in order to make a decision for the next 3 years
planning cycle on the number of officers to retain or recruit in order to keep the Marine Corps at
full strength. Thus, the data entry information is essential in order to make prediction on the
future horizon planning cycle.
However, as seen in Figures 9 and 10, the information provided by this data entry is
clustered together to make a sentence in order for the data entry to resemble a sub-process. For
example, in Figure 11 the terminology “Get aggregate accession mission from MPP-20 (broken
out by male/female)” is not of the standard terminology standard we have mentioned so far. It is
in the form of a request and some information has to be gathered in order to accomplish the task.
Therefore, this sub-process should be treated in this context as an input as opposed to a subprocess. Thus, the “Get aggregate accession mission from MPP20 (broken out by male/female)”
sub-process should be broken down into smaller sub-process of an input instance and can be
written as MPP-20 produce Output Aggregate Accession Rate Has_Property Male (or Female) or
Male (or Female) Is_Property_Of Aggregate Accession Rate Is_Outputed_By MPP-20. The new
terminology standards make it a lot easier to differentiate between generic relationships
(associative relationship, equivalence relationships and hierarchical relationship) and input
relationship types. In Figure 12 and Figure 13, the MPP mapping differentiates between the
generic sub-processes and data entry and thus, further clarifies the relationships between the
terms.
41
Figure 12: Shows the use of input terminology relationships in forecasting enlisted accessions
training.
42
Figure 13: Shows the use of input terminology relationships in forecasting Officer Accessions
training.
43
In both terminology graphs there are missing data sources from some of the information
requirements. However, due to the removal of semantic heterogeneity in the data entry by the use
of a well-structured thesaurus terminology standard, it is a lot easier to see the connection
between the source of the data entry MPP-20(Manpower Plans and Policy, Enlisted Plans) and
the input requirements. Thus, all input criteria have a data source from a business operation and a
data entry to a sub-process. Since both terminology graphs share similar input criteria both,
different MPP business operations input source. The input criteria can be represented as a subprocess in which all the data entry are gathered or calculated. For example, the data source of
most of the activities in the “Forecast enlisted initial Accessions Training” are from the MPP20(Manpower Plans and Policy, Enlisted Plans) department which is processed by in input
criteria before being sent to the “Forecast enlisted initial Accessions Training”. Take note that in
both the terminology graphs the input criteria is the same in the enlisted case as in the officer
case. This situation where enlisted cases are treated separately from officer cases, but have similar
sub-processes, arises all over MP processes and they are almost always the same process with
different data sources.
Therefore, the input criteria sub-process can be viewed as seen in Figure 14 as a subprocess with an input source and an output data entry. This sub-process will be used in the
forecasting of officer and enlisted accession management.
44
Figure 14: shows the input sub-process that can be used in both the officer and enlisted accession
management.
Thus, the process space can be further simplified in order to reduce the issue of semantic
heterogeneity amongst terminologies in the process space. Furthermore, the relationship between
the forecasting of accession management and the business operational department can be depicted
as seen in Figure 16. The figure clearly distinguishes between a sub-process and an input criteria
process which elevates the issue of semantic heterogeneity.
45
Figure 15: Depicts the relationship between a sub-Process and the data entry
4.2.3 Employing the use of data analysis on data entry
There is no clear description on how the data collected by the input criteria process are
used to make decisions among various sub-processes or how the values are passed down among
the sub-processes. For example, the “forecasting initial accessions training” sub-process and end
strength plan will be computed based on what the USMC HRDP department believes is the need
in the future time horizon. This information will passed down and adjusted among various
department sub-processes based on what they believe is visible before getting to the “forecasting
initial accessions training” sub-process. Thus, the full career options of a Marine has to be
considered by the MPP business operations during the development of the retention rates,
attrition rates, school seat allocation, and special assignment allocation. The MPP business
46
operations plans must also consider factors the plan is attempting to shape, such as the end
strength, current and target inventory budget and policy constraint.
Then billets of the “forecasting initial accessions training” sub-processes are filled based
on the future time horizon end strength requirement received from the “forecast enlisted T2P2”
sub-process, the accession rate and attrition rate information retrieved. The future end strength of
the sub-process will be optimized by balancing the accession and attrition rate. However,
balancing the accession and attrition rate is analogous to UPS redistributing its route when some
of its trucks are unavailable because they are being maintained in a shop or during holiday
periods when the amount of delivery increases. In the case of UPS, they can optimize their
strength by the redistribution of working trucks across various locations in order to account for
the loss in manpower. The reason why UPS can make this assumption is because all UPS trucks
are identical, Marines are different.
Therefore, more information about the individual Marines are required in the model in order
to make better predictions of the end strength. The sub-processes of the MPP business operations
should tailor the forecasting of specific Marine populations using the following dimensions:
1. Grade
2. MOS
3. YOS
4. Age
5. Level Of education
6. Combat experience
7. Overseas tour
8. Marital Status
9. Parenthood Status.
47
Furthermore, in the enlisted populations the leadership progression flow of individual
Marines is in the form of a leadership triangle. Thus, there are more need for junior enlisted
Marines as seen in Figure 16. Therefore in order to keep the Marines at full strength, the
population at each organizational level has to be kept at full strength. The problems with the
organization of enlisted marine populations per MOS are:
1. Movement between ranks requires time in service and the MOS may not be qualified
personnel to occupy some positions at a higher level of the organization.
2. At higher levels of the organization, only enlisted Marines from feeder MOS (MOS with
similar training) can transfer into the MOS with additional schools and training.
3. Issuing promotional or retainment bonus in order to retain qualified Marines in a
particular MOS.
4. Issuing enlistment bonuses to new recruits in order to fill the junior enlisted Marine
because the junior enlisted rank is the largest population of the MOS.
Figure 16: Organization structure of enlisted marine population per MOS
48
Thus, in order for the statistical tool to be successful, it needs to be able to access
information on each individual Marine and forecast the strength of the MOS in the future time
cycle based on the four factors stated above. Therefore, the process model should have a tool that
retrieves information based on the nine dimensions stated above and compute the end strength of
the MOS based on the end strength requirement per MOS issued by the USMC HRDP.
In developing the requirements of the sub-process, capable mathematical analysis tools
has to be created for managing the MPP. Therefore, it becomes necessary to identify the forces
that influence the sub-processes accountable for the dynamics of the MPP (Table 5). The MPP
management precisely needs to optimize the control mechanism in order to optimize the MPP
process. The MPP business operations takes into consideration the full spectrum of career
availability to each Marine when developing allocations for programs and special assignments,
retention rates, school seat allocations and attrition rates. The MPP must also consider constraints
and policies such has end strength, current inventory budget and target inventory.
Table 5: Forces affecting the MPP
Data Source
Control Mechanism
Accession
Accession Plan: Classification Plans & Execution, Training Input Plan, Bonuses
Employment
Billet staffing & assignments, Training staffing & assignments, Overstaff staffing &
assignments, Mobilization assignments
Progression
Progression plans & execution, including promotions, re-enlistments and lateral moves
Transfer
Transfer Plans including prior service Active & Reserve recruiting
Attrition
Employment policy (e.g. priority given to individual preferences)
The control mechanism is a billet of fundamental requirements and derived requirements
at any given future time horizon, which also includes the infinite horizon. The goal is to minimize
49
the difference between the end strength requirement and employment of the actual force as seen
in Figure 18. In a given future time horizon, the derived requirements are generally in
disagreement with the fundamental requirement. Therefore, an approach on balancing both
requirements is required. The employment control mechanism is the piece of the MPP which
determines to what degree each requirement is met.
Optimization of the average of the fundamental requirements and derived requirements over a
given time window is an intuitive approach but will generally result in concentrated periods with
extreme mismatches and shortages. Therefore, constraints of the requirements are needed as well.
Thus, dynamically optimizing the fundamental employment has to be done iteratively and
cyclically, in a 3 step process:
1. Assessing the fundamental and derived requirements metrics in relations with the current
employment inventory and how it relates to present inventory requirements,
2. Forecasting the future fundamental and derived requirements metrics using the control
mechanisms in search of an optimal control procedure, and
3. Executing the optimal employment solution found in step 2.
50
Figure 17: Shows a sample graph of the maximization of the employment quality (From: Marine
Corps Software requirements Specification [26])
51
Figure 18: Perpetual management control cycle (From: Marine Corps Software requirements
Specification [26])
After step 3, the cycle repeats itself as illustrated in Figure 18. There are potentially many
solutions for this problem. However; majority of the solutions will end up being not feasible due
to the constraint placed on the control mechanisms.
This information will be viewed in the process space of the process model as a data entry
with retrievable attributes and values. For example, if the data entry of the “Forecasting Enlisted
52
Initial Accessions Training” sub-process is queried, the control mechanisms that make up the
process and how decisions are made should be provided to the user as follows.
1.
Forecast Enlisted Initial Accessions Training
a.
Has Parent Process: Forecast Enlisted T2P2
b.
Is Outputted By: MPP-30
c.
Data Entry: Accession
i.
Has control Mechanism: Classification Plans & Execution
ii.
Has control Mechanism: Training Input
d.
Data Entry: Attrition
i.
Has control Mechanism: Employment policy
e. Has Process Requirement: For each MOS_i, [Boot_Out_Manyears x (MOS_i /
Total_Class_Plan) x (MOS_i_time_to_train) / 365] averaged over 3 years of class plan
data < |E(t+1) –R(t+1)|
f.
Has Fundamental Requirements: R(t +1)
The process requirement terminology relation can be visualized as constraints on the
employment process and is used in order to generate optimal employment solutions for the
“Forecast Enlisted Initial Accessions Training” sub-process. Thus, the three additional
terminology standards “Has Process Requirement,” “Has End strength Requirement” and “Has
Funder mental Requirements” are tools used in analyzing and generating potential employment
solutions in the MPP business operations.
4.3 Framework of the Thesaurus Process Space
The process space of the process model is constructed using the relations standard
proposed in chapter 3(Table 3). The process space was further standardized based on the
53
requirement, needs and functionalities of the MP process map proposed in chapter 4. The Process
space structures the entire information in the MP process map data base thus, for the process
model to generate queries that can be understood at every level of the organization the
terminologies used have to be standardized based on its fundamental requirements of the TBPM.
The MP process map can be viewed from two perspective, namely technical and business expert
point of view. The technical expert point of view is a bird eye view of the entire sub-process that
makes up the MP process map. The technical expert view the MP process map from the system
point of view in order to understand the continuity of information among various sub- processes
(department).
The business expert point of view is a rigorous analysis of what the sub-processes
encompasses of and how it affects the rest of the organization. The business experts are usually
well knowledgeable about a particular sub-process and need more detailed information about the
sub-process. For example, the business expert wants to know how the information received by the
sub- processes and data generated based on a historical data set are broken down based on the
sub-process algorithm and how it is used to generate data and requirement for the following
stages of the MP process map. Thus, based on the technical and business expert point of view of
the MP process map the MP process space can be categorized into 2 categories, namely global
process space and sub-process process space.
The sub-process space explores all the attributes of a sub-process by providing a detail
map of what the sup-process is composed of. The sub-process space needs to be well defined in
order to facilitate a better understanding of the objectives, assessments and results of the subprocess and how it impacts the outcome of other organization. The sub-process space is broken
down into five major categories based on the fundamental requirements of all the forces affecting
the MP process as shown in Table 6. The sub-process space contains all the requirement and
54
functionality that influence the MP process model and provides the user with all the activities of
the sub-process when queried. In Figure 20, a depiction of the sub-process space when a subprocess is queried is illustrated has a map of the MP fundamental requirements in order to further
simplify the process space query-able knowledge base and making it machine accessible. The
global process space maps only the interaction between sub-processes and contains only two
types of relations namely Has_ Child_Process and Has_ Parent_Process as depicted in Figure
19.The process space abstract the user from the functionality, requirement and results of the
process model and provides only hierarchical relations among sub-processes. The process space
is limited to two relations in order to facilitate data exploration with query expansion of subprocesses and also to combat the issue of semantic heterogeneity among the sub-processes. Thus,
the sub- process space provides the user with a detail analysis of the inner workings of the sub
process while the global process space provides the user with a system point of view of the
interaction of various sub-processes.
Figure 19: This figure illustrates the process space among sub-processes in the MP process
model.
55
Table 6: Shows the attributes of the sub-process space
Terminology
Attribute
Department Information Process Owner
Process Role
List of Auditors & verifiers
Department Involved
Job Function
Process Description
Process Evaluation
Input & Output Set
Input Deliverables
Input Requirement
Has Source
Output Deliverable
Output Requirement
Has Target
Output Generated
Output Receivers
Data Source
Accession
Employment
Progression
Transfer
Attrition
Data Analysis
Software / GUI Used
Historical Data Used
Date Generated
Performance Measure Indicator
Process Sequential Logic
Data Entry
Fundamental Requirement
56
Figure 20: Process model sub-process space.
57
4.3.1 Software Implementation and Browser GUI
The process model is implemented using client-server architecture; the server is
implemented using a mixture of MultiTes PRO and Microsoft Visual Basic software while the
client is implemented in MultiTes PRO in order to facilitate web-base access by online GUIs. The
call level interface facilitates computer access while the GUI is used to facilitate human access.
The main advantage of using the client-server approach is the facilitation of asynchronous queries
by multiple users without multiple programs overhead running.
4.3.2 Server Interface
The MultiTes PRO and Microsoft Visual Basic software’s are used in implementation of
the server interface. The MultiTes PRO software is used in constructing the process space of the
process model by mapping the sub-processes of the organization business operations and also acts
as a repository for the process models, thereby facilitating the creation and evaluation of new subprocess. The Microsoft Visual Basic software is used as the forecasting analysis tool in which the
control mechanism and end strength requirements can be adjusted by the user. When the
management controls analysis option is clicked on the call level interface, a second screen with
the data analysis tools poops up, allowing the user to perform analysis of the MPP business
operations.
4.3.3 Call level Interface
The thesaurus terminology was used to construct the call level interface in order to
facilitate functional calls using the MultiTes PRO software. The process model implementation is
based on a generic object in MultiTes PRO, with methods of accepting inputs and returning
information. In Table 7, a list of the functions arguments and returns are given.
58
Table 7: Process model call level interface
Function
Argument
Return
Find ancestors
of: sub-process
list <sub-process>
Find common ancestors
of: list <sub-process>
list <sub-process>
Find immediate relatives
of: sub-process ,by: relation
list <sub-process>
Find semantic distance
from: sub-process ,to: sub-process
distance
Find shortest Path
from: sub-process ,to: sub-process
list <sub-process>
Find neighborhood
around: term radius: distance
list <sub-process>
List all Path
from: sub-process ,to: sub-process
list <Path >
Find data entries
of: sub-process
list <data entry>
Find Process requirement
of: sub-process
list <requirement>
Find End strength requirement
of: sub-process
list <requirement>
Find common data entries
of: list <sub-process>
list <data entry>
4.3.4 Process Model GUI
Using the basic thesaurus and process model definitions of relations and graph
implementations in Chapter 3, the process model content and form can be implemented with
respect to the thesaurus terminology standard relations in order to facilitate manipulation of the
MP process space. The GUI for the process model has three screens as shown in Figures 21-24.
The first screen provides the user with terms organized alphabetically. When a term is clicked, a
second screen pops up displaying all of its relationships organized by its relations in order to
facilitate querying in terms of semantic paths between two different terms and to facilitate data
analysis of the sub-process management control cycle’s process space. The third screen shows the
advanced search tool used to facilitate data analysis of the process space.
59
Figure 21: Terms listed alphabetically on the main screen of the TBPM.
60
Figure 21: Second screen when a term is clicked
Figure 22: Advanced search tool displayed in the third screen
61
4.4 Proposed Framework - Example Implementation
To further understand the MP process space an example implementation illustrating the
functionalities of proposed framework is introduced. The MP process affects and is affected by
decisions made in other departments such as the Manpower Management (MM) process,
Structure & Manning (TFSD) process, Training& Education (TECOM) process, etc., therefore
the framework should focus more on the connectivity of the process spaces. There are also, bidirectional data being generated and transferred among sub-processes in this department however,
due to the lack of understanding of each other’s process space, querying of each other’s process
space becomes impossible. Thus, the framework will illustrate how the bi- directional data
transfer within the entire organization (e.g. how the transfer of data is accomplished and what
terminologies are used among the department) is accomplished, the use of a thesaurus to map the
process space and the benefits of using a thesaurus process space. The assumptions made during
the illustration of the framework are, each department creates its own TBPM using its own
version of the thesaurus terminology standard, and each department has limited to no knowledge
about the other department process and the only mode of data transfer is one-on-one(online data
transfer).
The process spaces of the MP process, MM process, TFSD Process and TECOM Process
are reproduced using different versions of the TBPM thesaurus terminology library (The
terminology and relations table can be seen in Appendix A). The MP process space is used as the
benchmark in studying the semantic similarities between various process spaces benefits and
capabilities. An example will be used to illustrate how the thesaurus will be used to generate
information by the user. An user may need some information on how Authorized Strength Report
(ASR) data is utilized, reproduced and transferred within the organization. The user will undergo
this following process in order to generate useful results:
62
1.
Use the thesaurus to search the process space of the MP process for any information
concerning the ASR input deliverables, output deliverables, process logic and process
owner information.
2. Use the information linking the departments and information gathered about the ASR in
searching other departments process space
3. Annotate similar processes from other process space in order to make it easier for others
to query the process space.
4. Develop a process that links the MP process space to the order process space with respect
to the ASR data and information.
In doing so, we found numerous processes that link the MM process and TFSD Process to the MP
process. The processes use and update the ASR data however; the initial ASR data is generated in
the TFSD process where it is known both as a process and an output deliverable of the TFSD
process. In the MM process it is used as a benchmark as a means to recreate the MSR process
because the ASR was found not to be feasible. Thus, the MM process uses a newer version of the
ASR data and calls it MSR. The following are the benefits of using a thesaurus in creating the
process space:
1. It is possible to search the process space in terms of the terminology due to the thesaurus
being used to create the process space
2. Using a thesaurus made it possible to search for terminologies based on a subject
category
3. It is easy for a new user to use the process model with little to no knowledge about a
process model because of its similarity to the thesaurus
4. Using the thesaurus made it possible to find physical connectivity between various
process spaces.
63
5. Using the thesaurus to create the process space provide a structural language for of the
process model which makes querying the process space efficient and effortless.
Application of a thesaurus in process modeling is a valuable tool in most linguistic
querying of the process space. The results obtained prove the effectiveness of using a thesaurus in
creating the process space. The use of a thesaurus in creating the process space provided a
controlled vocabulary of selected list of words which are then used to identify units of
information for information searching and retrieval. The controlled vocabularies provide a one-toone correspondence between words by clarifying the issues of homographs and synonyms which
reduces the ambiguity of the process space. In other words a controlled vocabulary makes a
process space easier to search.
64
Chapter 5
Validation
5.1 Validation
The TBPM was validated and analyzed based on its effectiveness in modeling a process
and in accordance to its compliance with the ISO process modeling requirements. The validation
and analysis of a BPM is a crucial process in ensuring the TBPM meets all standardized
requirements of a BPM. In this thesis, the TBPM was validated and proven based on its
compliance with the ISO 9001:2008 process approach requirement. The process approach
requirement is described by the ISO 9001:2008 standard as:
"The application of a system of processes within an organization, together with the
identification and interaction of these processes, and their management" [23].
In order to assure the TBPM truly behaves as anticipated, it becomes necessary to
account for how individual activities of the process behave when it is executed. The ISO
9001:2008 process approach is well-established in the area of process modeling and takes into
account how individual actives in the process space behave in achieving formal process modeling
language.
The 9001:2008 standard documents places an emphasis on managing the key processes
by properly documenting the interaction of the processes. The requirement for managing the
processes are scattered under various heading throughout the document. Figure 23 shows the
model representation requirement and an overview of how the ISO 9001:2008 process approach
works in achieving its goal of automating the process model’s process space.
The standard requirement for the management of the processes can be found in several
chapters in the ISO 9001:2008 document and the most relevant once are listed in Table 8. Also in
65
Table 8, is a comprising of the TBPM guideline and ISO 9001:2008 process approach
highlighting how all the requirements are met with.
Table 8: ISO 9001 and TBPM Key Process Space Management Requirement check list.
Reference
ISO Key Process Space Management TBPM Key Process Space
Requirement
Requirement
Management Requirement
Met
4.1 (a) &
NOTE; 7.1;
7.2; 7.4.1;
8.1
4.1 (d); 6.0;
7.2.3; 7.3.3
(b); 7.4.2
Identification of the key processes
Define the process and its
relationship to other process
Yes
Identify the resources required in
each processes and create a map of
its process logic in order to ensure its
task are completed.
Identify the input data, input
deliverable and process logic
Yes
4.1 (b);
4.2.2 (c)
Identification of how the processes fit Develop a process and
and impact each other
relationship map of the process
space
Determine a mode of communication Define all the types of
in order to ensure everyone affected relationships in the process
or perform the processes
space with emphasis on
understand the working of the
standardizing the relations
processes
Assign the responsibility of managing Identify the process owner
the processes on a regular basis
relation
Yes
4.1 (e);
5.6.2 (c);
8.2.3; 8.4
(c)
4.1 (c); 5.4
Ensure the objectives of the
processes are being met by
monitoring and assessing the
performance of the processes.
Determine the criteria of measuring
the performance of the processes
based on its process objectives
Define the process performance
measure in order to monitor
and assess the process space
Yes
Define the performance
measure criteria in the process
space
yes
5.6.3 (a);
8.5
Identify what can be done to improve
the overall performance of the
processes based on the key process
measures
Establish a procedure for controlling
the processes and how they relate to
the overall objectives of the
organization
Define the how the overall
performance measure can be
improved
Yes
Define standardized
terminology in order to help
control the vocabulary in the
process space.
Yes
5.5.3
5.5.2 (a)
4.2.1 (d)
Yes
Yes
66
Figure 23: Shows the overview of the ISO 9001:2008 process approach requirement
Therefore, we can see from Table 8 that the application of the thesaurus in the process
space of a BPM is an effective and novel approach in mapping and defining the process space of
a BPM. Based on Table 8, the TBPM meets the standard requirements of the ISO 9001:2008
process approach requirement thus; the TBPM is validated by the ISO 9001:2008 process
approach. Thus, since the TBPM meets all the requirements of the ISO 9001:2008 process
approach, the TBPM is validated has an effective process model.
67
Chapter 6
Conclusions and Future Work
6.2 Conclusion
We have shown in this thesis that the lack of semantic representation of the process
space of most process modeling techniques is a major obstacle in solving the issue of semantic
heterogeneity among process models. We also showed that it was possible and necessary to
resolve the issue of semantic heterogeneity in BPM with domain specific terminologies and
interfaces. In combating the issue of semantic heterogeneity, we proposed a combination of a
thesaurus structured language and a BPM which we called a Thesaurus Business Process Model
(TBPM).The architecture and requirements of the TBPM were described, outlined and
implemented based on the Marine Corps manpower process (MP) and the results obtained
showed an increase in automation of the process space. Next, we validated the TBPM based on its
compliance with the ISO9001 process approach standard requirements and met all the standard
requirements.
Furthermore we showed that the TBPM is an extension of the BPM with a semantic
annotation of the process space which was proposed to increase the automation of interpretation
of the process space. The process space of the TBPM was structured using thesaurus as a means
of providing semantic description of the process space and also to allow an intelligent query of
the process space with minimum to no knowledge of its content. Although the approach is still
growing, we have obtained very promising results towards reducing semantic heterogeneity
among process models thanks to the thesaurus inexplicitly providing a structure to the process
space. It is very important to note that although; the main objective of this thesis was providing a
simplistic technique that could be used to navigate through process spaces with an issue of
68
semantic heterogeneity, the major achievement was providing a low cost scalable reasoning
technique that can be implemented by anyone with a knowledge of a thesaurus.
6.2 Future Work
The TBPM environment enriches the BPM by providing the fundamental building blocks
of making it easier to search the process model for valuable information by a semantic annotating
of the process space. However, as the size of the process space increases it becomes more
difficult to search the process space. Thus, it becomes important to fully automate the mediation
of process spaces by finding a semantic distance metrics between them.
The semantic distance metrics is defined as the degree of closeness between two
terminologies in different process models. The distance metrics between two terminologies can
be broken down into three different parts namely syntactic, linguistic and contextual distance
metrics.
Given two elements labels, the syntactic distance metrics is used to compute the degree
of similarity by measuring the string- edit distance between terms. Maedche and Staab [25]
present an approach based on Levenshtein [24], used to measure the similarity between terms.
This approach is based on measuring the minimum number of token insertions, deletions, and
substitutions required to transform one string into another, and a dynamic programming algorithm
was used to compute the approach. The String Matching (SM) measure is given by:
SMsyn (VA, VB)∶= 𝑚𝑎𝑥 �0,
min(|𝑉𝐴| ,|𝑉𝐵|)− 𝐸𝐷(|𝑉𝐴|,|𝑉𝐵|)
�
min(|𝑉𝐴| ,|𝑉𝐵|)
∈ [0, 1]
Where, ED is the Edit Distance between two terms. For example, ED (verified invoice,
verification invoice) = 6. The values of SM are between 0 and 1, where 1 means a perfect match
and zero means a bad match. For example, SM (verified invoice, verification invoice)
69
16−6
�=0.625.
16
=�
However, the SM approach can provide deceptive results at times. For example,
when two terms have similar resemblance but share no meaningful relationship (e.g. lower and
rower). Thus, in order to get better a syntactic distance metrics, a syntactic distance metrics that
takes into account the meaning of a word has to be taken into account.
As opposed to measuring the string- edit distance of terms, linguistic distance metrics
measures the degree of linguistic similarity between the process element names. The linguistic
distance metrics takes into account only the number of synonyms the two terms have in common.
For instance, when the term verifies and confirm are submitted to a thesaurus, the common
synonym generated might be: authenticate, certify, check, corroborate, document, find out,
justify, prove, support and test etc. Therefore, there is a linguistic relationship between verify and
confirm. The comparisons of terms require a pair wise manual review of terms by counting the
number of shared relationships in a thesaurus. The major issue the linguistic distance metrics help
resolve is the representation of element names using verb, nouns or adverbs interchangeably.
The contextual distance metrics is the measure of the degrees of similarity between
processes elements name by examining the context in which the concept instance occurs. Thus,
this structural similarity measure computes the similarity between two elements labels (node)
based on their relationships to similar nodes. Preceding model process elements are referred to as
input context while succeeding model process elements are referred to as output context. In order
to measure the degrees of context similarities relationship between the elements the ambiguities
in element directionality has to be eliminated. For example, element label relationships in a BPM
have to be expressed in the form of the element label1 relationship with element label 2 have to
form a sentence when full relationship elements labels are in use. Each of the context elements
relationships influences the distance metrics. The hierarchical relations are the most important
relationships and influence the similarity measure more than equivalence relationship, which are
70
mostly relevant to identifying the element label direct relationship. The different degrees of
relationship influence the context instance thus, weight are used to assign the degree of influence
the context instance has on the relationship. In computing the contextual degree of freedom
between two processes an element label (VA) in BPM1 will be compared with a set element labels
(VBj) in BPM2. Let SMcon(VA,VBj) denote the distance metrics function used in calculating the
contextual distance between VA and VB and WKI be weighted average between both terms. Then
contextual distance metrics is defined as:
∑𝑛
𝑖=1 max(𝑊𝑘𝑖∗�𝑆𝑀𝑘𝑖(𝑉𝐴,𝑉𝐵𝑗)�
SMcon(VA,VB)=
This needs to be validated thoroughly in the future.
∑𝑛
𝑖=1 𝑊𝑘𝑖
∈ [0, 1].
71
Appendix A
Terminology and Relations Tables
Below is a list of tables of the terminologies used in creating a map of the entire USMC
HRDP process map. Each table is grouped based on the department, enlisted and officer
information.
Table9: Shows the MM Recruit Distribution process space
Business
Process
Process Owner Parent Process
HRDP
USMC
Manpower & Reserve Affairs
M&RA
HRDP
Manpower Management (AC)
MM
Manpower & Reserve Affairs
Distribution
MMEA-1
Manpower Management (AC)
Classication
MMEA-11
Distribution
Set Inventory
MMEA-11
Classication
enter date range for boot camp
graduation
MMEA-11
Set Inventory
import TIMS data for bootcamp
graduation dates in window = Bn,
Company, Platoon Ranges w/
grad date for each platoon
MMEA-11
Set Inventory
import MCRD data from each
MCRD containing expected
bootcamp grad date for each
platoon (currently comes by
email -> in TFMMR should go to
MCRC Portal)
MMEA-11
Set Inventory
compare TIMS & MCRD data to
verify platoon #s & grad dates correct TIMS data as needed
MMEA-11
Set Inventory
use platoon i.d.'s to pull ODSE
data on recruits (enable
m.s.word-like printer options for
mutiple ranges of co's &
platoons) (format of user inputs =
E/W, Co., Platoon_Start1,
Platoopn_End1, Platoon_Start2,
Platoon_End2,…,Platoon_StartK,
Platoon_EndK
MMEA-11
Set Inventory
Level
0
1
2
3
4
5
6
6
6
6
6
72
use platoon i.d.'s to pull MCRISS
data on recruits (enable
m.s.word-like printer options for
mutiple ranges of co's &
platoons) (format of user inputs =
E/W, Co., Platoon_Start1,
Platoopn_End1, Platoon_Start2,
Platoon_End2,…,Platoon_StartK,
Platoon_EndK
REVIEW INVENORY DATA using
MCRISS data as backup to
verify/populate ODSE if missing
fields etc
use platoon i.d.'s to pull
estmiated MCT grad dates from
TIMS (estimate 1st possible MCT
grad_date by MCT schedule
lookup with key = must_grad_by
<- boot_camp_grad_date)
merge MCT platoon grad date w/
inventory data to give every
recruit an MCT grad date
estimate
pre-run validation of inventory
data - check for missing fields
used in classification rules e.g.
driver's license, color vision, etc)
human views inventory data one
last time
Set Quotas
enter date range and import full
class schedule from TIMS
review/edit quotas to allow
overfill, add future classes not yet
in TIMS, etc
Manage Rule Sets
for each Class_ID(CID); title =
MOS (full or training MOS and
additional qualifiers, e.g. 0311E
or O311W); test_requirement
(desired, minimum for each test);
MCC, IMOS, Def Priority (of
seat/school/MOS); PEF's eligible
for MOS, Exclude Prasp flag
MMEA-11
Set Inventory
6
MMEA-11
Set Inventory
6
MMEA-11
Set Inventory
6
MMEA-11
Set Inventory
6
MMEA-11
Set Inventory
6
MMEA-11
MMEA-11
Set Inventory
Classication
6
5
MMEA-11
Set Quotas
6
MMEA-11
MMEA-11
Set Quotas
Classication
6
5
MMEA-11
Manage Rule Sets
6
73
for each Class_ID(CID); use above
data to reference MOS
application data set and cross
check rules with MOS
requirements from MOS app;
edit any rules as necessary
Run Optimization
set dictionary
set inventory
set quotas
manually enter E/W/BOTH
make any special (manual) prerun assignments - see special
assignments)
pre-validation checking for PEF
with no quotas
submit run
Review/Adjust Output
see detailed output spec/format
including PRASP
recommendation
manually assign all unassigned by
model (same process as manual
classification and reclassification)
select portion of assignments to
publish (defaults to the current
week of bootcamp grads), given
that the model was run for a
superset of recruits and quotas
Publish Output (workflow =
classification authorities)
Re Classication
Receive Notification
naval message from school one
recruit at a time (pull marine data
by last 4 of SSN)
Set Quotas
Import available quotas from
TIMS based on date range (start
date defaults to present date but
sometimes need to look in the
past as well)
MMEA-11
MMEA-11
MMEA-11
MMEA-11
MMEA-11
MMEA-11
Manage Rule Sets
Classication
Run Optimization
Run Optimization
Run Optimization
Run Optimization
6
5
6
6
6
6
MMEA-11
Run Optimization
6
MMEA-11
MMEA-11
MMEA-11
Run Optimization
Run Optimization
Classication
6
6
5
MMEA-11
Review/Adjust Output
6
MMEA-11
Review/Adjust Output
6
MMEA-11
Review/Adjust Output
6
MMEA-11
MMEA-11
MMEA-11
Classication
Distribution
Re Classication
5
4
5
MMEA-11
MMEA-11
Receive Notification
Re Classication
6
5
MMEA-11
Set Quotas
6
74
show unlisted classes for hard to
fill MOS (e.g. last years class that
hasn't shown up in tims yet)
validate quotas
Manage Rule Sets
for each Class_ID(CID); title =
MOS (full or training MOS and
additional qualifiers, e.g. 0311E
or O311W); test_requirement
(desired, minimum for each test);
MCC, IMOS, Def Priority (of
seat/school/MOS); PEF's eligible
for MOS, Exclude Prasp flag
for each Class_ID(CID); use above
data to reference MOS
application data set and cross
check rules with MOS
requirements from MOS app;
edit any rules as necessary
Compute Rankings
filter quotas by eligibility (ignore
PEF for reclass)
rank eligible quotas based on
recruit characteristics
Manual Reclassification Decision
point & click to make assignment
Publish reclass decision
generate unit diary entry in
UDMIPS ;
reduce associated quota by one
Special Assignment Classication
Command Distribution
MMEA-11
MMEA-11
MMEA-11
Set Quotas
Set Quotas
Re Classication
6
6
5
MMEA-11
Manage Rule Sets
6
MMEA-11
MMEA-11
Manage Rule Sets
Re Classication
6
5
MMEA-11
Compute Rankings
6
MMEA-11
MMEA-11
MMEA-11
MMEA-11
Compute Rankings
Re Classication
Manual Reclassification Decision
Re Classication
6
5
6
5
MMEA-11
MMEA-11
MMEA-11
MMEA-11
Publish reclass decision
Publish reclass decision
Distribution
Distribution
6
6
4
4
Table10: Shows the MM Enlisted staffing process space
Business
Process
Process
Owner
Parent Process
HRDP
USMC
Manpower & Reserve Affairs
M&RA
HRDP
Manpower Management (AC)
MM
Manpower & Reserve Affairs
Enlisted Staffing
MMEA-5
Manpower Management (AC)
Level
0
1
2
3
75
Enlisted Inventory Management
MMEA-5
MMEA-5
Enlisted Staffing
Enlisted Inventory
Management
Enlisted Inventory
Management
validation, conversion of
inventory data
validation, conversion of
inventory data
Enlisted Inventory
Management
Pull current inventory from ODSE
MMEA-5
validation, conversion of inventory data
MOS conversions (e.g. rollup of 0121 0151
0193 into 0111)
MMEA-5
other conversions
Set target staffing date for forecast and for
fixed vs free determination
forecast attrition ~ not currently done;
could be mix of historical rate and hard
data (declared retirements, etc)
forecast promotions ~ not currently done;
could be mix of historical attrition rate and
GAR for vacancies
forecast accessions ~ not currently done;
could be classification plan (e.g. AT&T
projection & simulation), OR could also
incorporate school seats via student
distribution model result using real recruit
data or projection & simulation
forecast chargeable population ~ current
method of using current inventory as
forecast trivially supports chargeable
determination, which would not be so
easy with other methods
forecast division of inventory into fixed &
free subsets
EDD, EDA (if already on new orders), if on
tour with RTD rotation tour date if TCF
tour control factor combine with DCTB
date current tour began; for current
chargeable Marines; open tour = min time
and max time (fixed til min)
all brand new classified Marines are
chargeable and restricted to billets within
their MOS (no free b-billets)
Enlisted Staffing Requirements
Management
MMEA-5
MMEA-5
Enlisted Inventory
Management
5
MMEA-5
Enlisted Inventory
Management
5
MMEA-5
Enlisted Inventory
Management
5
Import ASR
Compare w/ Previous ASR
MMEA-5
MMEA-5
MMEA-5
4
5
5
6
6
5
MMEA-5
Enlisted Inventory
Management
Enlisted Inventory
Management
MMEA-5
forecast division of inventory
into fixed & free subsets
6
MMEA-5
forecast division of inventory
into fixed & free subsets
6
MMEA-5
MMEA-5
Enlisted Staffing
Enlisted Staffing
Requirements Management
Enlisted Staffing
5
5
4
5
5
76
Copy and Save as MSR
MMEA-5
Edit & Validate MSR
MOS deletions, additions & conversions
MCC conversions deletions, additions &
conversions
MOS-grade mismatches
SDA edits: remove billets for SDA and
replace with inventory of SDA so req = inv
and use notional MCC code to make
invisible to Monitors
MMEA-5
MMEA-5
Requirements Management
Enlisted Staffing
Requirements Management
Enlisted Staffing
Requirements Management
Edit & Validate MSR
MMEA-5
MMEA-5
Edit & Validate MSR
Edit & Validate MSR
6
6
MMEA-5
6
B-Billet Plan
B-billet plan (map some leave some free) mapped = some mapped to a group some
mapped to partifular MOS
excel version of ASR/MSR to L.A. Wright;
get format w/ tabs and color codes and
rearranged columns (currently TFSD
formats)
get processed excel sheet back from L.A.
Wright; copy and paste b-fil plan into MSR
via ESGM interface - > constitutes
specifying a PMOS for some number of bbillets and possibly leaving some free bbillets free (i.e. 0000) - b-billets only
MMEA-5
Edit & Validate MSR
Enlisted Staffing
Requirements Management
MMEA-5
B-Billet Plan
6
MMEA-5
B-Billet Plan
6
MMEA-5
6
Optional Compare MSR with Previous MSR
MMEA-5
Additional SG Manager changes
edit priorities of MCC and of individual
billets
change ASR 3-level priorities to 6-level
system, possibly changing billets within an
mcc to different levels
change pecentage fill target for each of
the 6 priorities
other edits based on analysis and staffing
directives
Enlisted Staffing Rule Management
Organize MSR billets into Billet Control
Sets
MMEA-5
B-Billet Plan
Enlisted Staffing
Requirements Management
Enlisted Staffing
Requirements Management
Additional SG Manager
changes
MMEA-5
MMEA-5
MMEA-5
MMEA-5
MMEA-5
MMEA-5
edit priorities of MCC and of
individual billets
edit priorities of MCC and of
individual billets
Additional SG Manager
changes
Enlisted Staffing
Enlisted Staffing Rule
Management
5
5
6
5
5
5
6
7
7
6
4
5
77
standard billet groups: specific PMOS
(Enlisted A-billets or necessary B-billets),
any Enlisted (free b-billet), any ground
Enlisted (semi-free b-billet), any aviation
Enlisted (semi-free b-billet), any Enlisted at
each grade
MMEA-5
groups by MCC for allowable PCA moves
of fixed inventory
MMEA-5
Organize MSR billets into
Billet Control Sets
Organize MSR billets into
Billet Control Sets
Organize MSR billets into
Billet Control Sets
groups for male only MCC
tag billets with Billet Control Set names =
ad hoc groups of rules - e.g. to enable fine
granularity e.g. to enable forcing exact
match of half of a set of identical billets
while allowing substitutions for the other
half) = everything has to be explicitly listed
in a billet control set
MMEA-5
Create/edit rules for each group
align implmentation of groups with
application of rules - bcs name, etc
specify marine characteristics of who can
fill billets in the billet group to which the
rule is applied
specify level of quality of fit for the
characteristics specified by the rule
MMEA-5
name the rule
MMEA-5
Create/edit default rules for each MOS
align implmentation of groups with
application of rules - bcs name, etc
specify marine characteristics of who can
fill billets in the billet group to which the
rule is applied
specify level of quality of fit for the
characteristics specified by the rule
MMEA-5
name the rule
MMEA-5
Review/Re-prioritize the rules
review/change the level of quality of fit of
each rule matching marine characteristics
to billet characteristics
MMEA-5
Create/edit default rules for
each MOS
Create/edit default rules for
each MOS
Create/edit default rules for
each MOS
Enlisted Staffing Rule
Management
MMEA-5
Review/Re-prioritize the rules
MMEA-5
MMEA-5
MMEA-5
MMEA-5
MMEA-5
MMEA-5
MMEA-5
Organize MSR billets into
Billet Control Sets
Enlisted Staffing Rule
Management
Create/edit rules for each
group
Create/edit rules for each
group
Create/edit rules for each
group
Create/edit rules for each
group
Enlisted Staffing Rule
Management
Create/edit default rules for
each MOS
6
6
6
6
5
6
6
6
6
5
6
6
6
6
5
6
78
Enlisted Staffing Optimization
Select MSR
Select MOS manual
Select Inventory Data Set
Select Substitution Rule Sets
Handle Special Duty Assignments (SDA)
SDA edits: give every SDA billet one (1)
staffing goal which accounts for current
inventory used above to set number of
SDA billets
Run Optimization
Optimize Fill of MSR billets
fill max number of manned billets up to
the target fill precentage with any
qualified marine, ensuring that any
shortages are distributed proportionally
across all mcc having the same
requirement for grade and mos at the
same priority, and with the constraint that
fixed marines do not require a pcs move
rearrange staffing goals to optimize fit
while preserving fill levels of each group of
billets defined by mcc, grade, mos and
priority
Optimize Distribution of Excess Inventory
MMEA-5
MMEA-5
MMEA-5
MMEA-5
MMEA-5
MMEA-5
Enlisted Staffing
Enlisted Staffing Optimization
Enlisted Staffing Optimization
Enlisted Staffing Optimization
Enlisted Staffing Optimization
Enlisted Staffing Optimization
4
5
5
5
5
5
MMEA-5
MMEA-5
MMEA-5
Handle Special Duty
Assignments (SDA)
Enlisted Staffing Optimization
Run Optimization
6
5
6
MMEA-5
Optimize Fill of MSR billets
7
MMEA-5
MMEA-5
7
6
fill max number of unmanned T/O billets
overfill T/O at non-excepted MCC,
proportionally distributing excess relative
to the number of T/O billets with the same
grade and MOS
overfill T/O at non-excepted MCC,
proportionally distributing excess relative
to the number of T/O billets with the same
MOS
Review Enlisted Staffing Solution
MMEA-5
Optimize Fill of MSR billets
Run Optimization
Optimize Distribution of
Excess Inventory
MMEA-5
Optimize Distribution of
Excess Inventory
Compute metrics
brief MMEA senior leadership &
MONITORS for approval
Optional Loop back to Requirements
and/or Staffing Rule Management and rerun optimization
MMEA-5
MMEA-5
Optimize Distribution of
Excess Inventory
Enlisted Staffing
Review Enlisted Staffing
Solution
Review Enlisted Staffing
Solution
MMEA-5
Enlisted Staffing
MMEA-5
MMEA-5
7
7
7
4
5
5
4
79
Publish Enlisted Staffing Solution
brief MMEA senior leadership &
MONITORS for approval
MMEA-5
MMEA-5
Enlisted Staffing
Publish Enlisted Staffing
Solution
Publish Enlisted Staffing
Solution
Publish Enlisted Staffing
Solution
export CSR in DETSOL format
import CSR in DETSOL format into
WebMASS
PUBLISH IN WebMASS (THIS IS AN ACTUAL
SOFTWARE OPERATION IN WEBMASS
TRIGGERED BY A MODEL MANAGER
SEQUENCE OF MENUS)
Recommend Enlisted Assignments
Optional Loop back to Requirements
and/or Staffing Rule Management and rerun optimization
Enlisted Assignments
MMEA-5
MMEA-5
MMEA-5
Publish Enlisted Staffing
Solution
Enlisted Staffing
5
4
MMEA-5
MMEA-8
Enlisted Staffing
Manpower Management (AC)
4
3
MMEA-5
4
5
5
5
Table 11: Shows the MM Officer Staffing process space
Process
Business Process
Owner
HRDP
Manpower & Reserve
Affairs
Manpower Management
(AC)
USMC
Officer Staffing
Officer Inventory
Management
Pull slate data from
MIAPPS (daily download
from web mass)
User Input of target staffing
date for aging and for fixed
vs free determination
incorporate planned
promotions
use 'select grade' for grade
in inventory data set
compare to 4-yr average
and add in user-controlled
percentage of forecast
change MOS based on
promotions and MOS
progression as specified in
manual
Parent Process
Level
0
M&RA
HRDP
1
MM
Manpower & Reserve Affairs
2
MMOA-5
Manpower Management (AC)
3
MMOA-5
Officer Staffing
4
MMOA-5
Officer Inventory
Management
5
MMOA-5
Officer Inventory
Management
Officer Inventory
Management
incorporate planned
promotions
MMOA-5
incorporate planned
promotions
6
MMOA-5
incorporate planned
promotions
6
MMOA-5
MMOA-5
5
5
6
80
incorporate planned EAS
remove people based on
approved retirements &
other slate loss MCCs
compare to 4-yr average
and add in user-controlled
percentage of forecast
import career designation
plan
remove people based on
career force designation
plan
MMOA-5
Officer Inventory
Management
5
MMOA-5
incorporate planned EAS
6
MMOA-5
incorporate planned EAS
6
MMOA-5
incorporate planned EAS
6
MMOA-5
6
incorporate t2p2 forecast
remove entry lvl trainees
based on MOS and/or MCC
(includes some H99 Monterey sao double
counting)
career lvl trainees by
reviewing MARADMINs
and/or school quotas by
MOS (for capt school)
import T2P2 manning
control data
adjust aggregate inventory
counts based on manning
control forecast
incorporate new lt's from
training pipeline
import MOS/TAS output
(counts by MOS)
adjust aggrgate counts
based on MOS/TAS data
PMOS/AMOS conversions
of inventory records
Officer Staffing
Requirements Management
MMOA-5
incorporate planned EAS
Officer Inventory
Management
MMOA-5
incorporate t2p2 forecast
6
MMOA-5
incorporate t2p2 forecast
6
MMOA-5
incorporate t2p2 forecast
6
MMOA-5
incorporate t2p2 forecast
Officer Inventory
Management
incorporate new lt's from
training pipeline
incorporate new lt's from
training pipeline
Officer Inventory
Management
6
4
Import ASR
MMOA-5
Compare w/ Previous ASR
MMOA-5
Copy and Save as MSR
MMOA-5
Edit & Validate MSR
MMOA-5
Officer Staffing
Officer Staffing Requirements
Management
Officer Staffing Requirements
Management
Officer Staffing Requirements
Management
Officer Staffing Requirements
Management
MOS conversions
MCC conversions including
notional MCC
MMOA-5
Edit & Validate MSR
6
MMOA-5
Edit & Validate MSR
6
MOS-grade mismatches
MMOA-5
Edit & Validate MSR
6
MMOA-5
MMOA-5
MMOA-5
MMOA-5
MMOA-5
5
5
6
6
5
5
5
5
5
81
B-billet plan
Compare MSR with current
Staffing
Export current CSR from
WebMASS in DETSOL
format
MMOA-5
Import DETSOL
Compare and output to
excel w/ 3 tabs: Old, New,
Diff (see format spec)
MMOA-5
Monitor Scrubb of MSR
Export MSR in DETSOL
format from MSR tool
Import DETSOL into
WebMASS
Monitors and Manager
simulataneously and
asynchronously editing in
WebMASS - montior
changes wait in queue manager accepts or reject
monitor changes
Export MSR in DETSOL
format from WebMASS
Import DETSOL into MSR
tool
Additional SG Manager
changes
edit priorities of MCC and of
individual billets
change ASR 3-level
priorities to 6-level system,
possibly changing billets
within an mcc to different
levels, which never
happens in the asr
change pecentage fill target
for each of the 6 priorities
other edits based on
analysis and staffing
directives
Officer Staffing Rule
Management
Organize MSR billets into
groups
standard billet groups:
specific PMOS (officer Abillets or necessary Bbillets), any officer (free b-
MMOA-5
Compare MSR with current
Staffing
Officer Staffing Requirements
Management
MMOA-5
Monitor Scrubb of MSR
6
MMOA-5
Monitor Scrubb of MSR
6
MMOA-5
Monitor Scrubb of MSR
6
MMOA-5
Monitor Scrubb of MSR
6
MMOA-5
Monitor Scrubb of MSR
Officer Staffing Requirements
Management
Additional SG Manager
changes
6
MMOA-5
MMOA-5
MMOA-5
MMOA-5
MMOA-5
Edit & Validate MSR
Officer Staffing Requirements
Management
Compare MSR with current
Staffing
Compare MSR with current
Staffing
MMOA-5
edit priorities of MCC and of
individual billets
edit priorities of MCC and of
individual billets
MMOA-5
Additional SG Manager
changes
MMOA-5
MMOA-5
MMOA-5
Officer Staffing
Officer Staffing Rule
Management
MMOA-5
Organize MSR billets into
groups
6
5
6
6
6
5
5
6
7
7
6
4
5
6
82
billet), any ground officer
(semi-free b-billet), any
aviation officer (semi-free bbillet), warrant officer billets,
LDO billets
groups by MCC for
allowable PCA moves of
fixed inventory
groups by MCC for like
commands
groups by MCC for mirror
commands
groups for critically short
MOS
Monitor Activity Code
(MAC) Partition
Billet Control Set Partition
[functionally same same as
ESGM but called BCS in
OSGM] (e.g. to enable
forcing exact match of half
of a set of identical billets
while allowing substitutions
for the other half)
Create/edit groups of MOS
e.g. "any ground officer",
"any aviation officer"
Create/edit rules for each
group
align implmentation of
groups with application of
rules - bcs name, etc
specify marine
characteristics of who can
fill billets in the billet group
to which the rule is applied
specify level of quality of fit
for the characteristics
specified by the rule
name the rule
Create/edit Default rules for
each MAC
align implmentation of
groups with application of
rules - bcs name, etc
specify marine
characteristics of who can
fill billets in the billet group
to which the rule is applied
specify level of quality of fit
for the characteristics
MMOA-5
Organize MSR billets into
groups
Organize MSR billets into
groups
Organize MSR billets into
groups
Organize MSR billets into
groups
Organize MSR billets into
groups
MMOA-5
Organize MSR billets into
groups
MMOA-5
MMOA-5
MMOA-5
MMOA-5
6
6
6
6
6
6
MMOA-5
Officer Staffing Rule
Management
Officer Staffing Rule
Management
MMOA-5
Create/edit rules for each
group
6
MMOA-5
Create/edit rules for each
group
6
MMOA-5
MMOA-5
Create/edit rules for each
group
Create/edit rules for each
group
Officer Staffing Rule
Management
MMOA-5
Create/edit rules for each
group
MMOA-5
MMOA-5
MMOA-5
MMOA-5
Create/edit rules for each
group
Create/edit rules for each
group
5
5
6
6
5
6
6
6
83
specified by the rule
MMOA-5
Create/edit rules for each
group
Officer Staffing Rule
Management
MMOA-5
Review/Re-rioritize the rules
6
MMOA-5
Officer Staffing
4
Select MSR
MMOA-5
Officer Staffing Optimization
5
Select MOS manual
MMOA-5
Officer Staffing Optimization
5
Select Inventory Data Set
Select Substitution Rule
Sets
MMOA-5
Officer Staffing Optimization
5
MMOA-5
Officer Staffing Optimization
5
Run Optimization
Optimize Staffing Goals for
MSR billets
Optimize Fill of MSR billets:
fill max number of manned
billets up to the target fill
precentage with any
qualified marine, ensuring
that any shortages are
distributed proportionally
across all mcc having the
same requirement for grade
and mos at the same
priority, and with the
constraint that fixed
marines do not require a
pcs move
Optimize Fit of MSR billets:
rearrange staffing goals to
optimize fit while preserving
fill levels of each group of
billets defined by mcc,
grade, mos and priority
Optimize Distribution of
Excess Inventory
fill max number of
unmanned T/O billets
overfill T/O at non-excepted
MCC, proportionally
distributing excess relative
to the number of T/O billets
with the same grade and
MOS
MMOA-5
Officer Staffing Optimization
5
MMOA-5
Run Optimization
6
MMOA-5
Optimize Staffing Goals for
MSR billets
7
MMOA-5
Optimize Staffing Goals for
MSR billets
7
name the rule
Review/Re-rioritize the
rules
review/change the level of
quality of fit of each rule
matching marine
characteristics to billet
characteristics
Officer Staffing
Optimization
MMOA-5
MMOA-5
MMOA-5
Run Optimization
Optimize Distribution of
Excess Inventory
MMOA-5
Optimize Distribution of
Excess Inventory
6
5
6
7
7
84
overfill T/O at non-excepted
MCC, proportionally
distributing excess relative
to the number of T/O billets
with the same MOS
MMOA-5
Compute metrics
review like and mirror
commands
Review Officer Staffing
Solution
MMOA-5
Compute metrics
review like and mirror
commands
Optional Loop back to
Requirements and/or
Staffing Rule Management
and re-run optimization
Publish Officer Staffing
Solution
brief MMOA senior
leadership for approval
brief MM senior leadership
for approval
brief M&RA senior
leadership for approval
export CSR in DETSOL
format
import CSR in DETSOL
format into WebMASS
PUBLISH IN WebMASS
(THIS IS AN ACTUAL
SOFTWARE OPERATION
IN WEBMASS
TRIGGERED BY A MODEL
MANAGER SEQUENCE
OF MENUS)
MMOA-5
MMOA-5
MMOA-5
Optimize Distribution of
Excess Inventory
Review Officer Staffing
Solution
Review Officer Staffing
Solution
7
5
5
4
MMOA-5
Officer Staffing
Review Officer Staffing
Solution
Review Officer Staffing
Solution
MMOA-5
Officer Staffing
4
MMOA-5
4
MMOA-5
Officer Staffing
Publish Officer Staffing
Solution
Publish Officer Staffing
Solution
Publish Officer Staffing
Solution
Publish Officer Staffing
Solution
Publish Officer Staffing
Solution
MMOA-5
Publish Officer Staffing
Solution
MMOA-5
MMOA-5
MMOA-5
MMOA-5
Table 12: Shows the Partners & Common Processes process space
Business Process
Process
Owner
Parent Process
HRDP
USMC
Organizational
Decisions
Advocates
HRDP
Operational Decisions
Deployment Cycles/
Ground MOS'
PP&O
Organizational Decisions
Logistics Decisions &
MOS'
I&L
Organizational Decisions
5
5
5
5
5
5
5
5
Level
0
1
2
2
85
Manpower Decisions &
Admin/Manpower
MOS'
Structure & Manning
TO&E
ASR
ASR
TOECR
TOECR Publication
TO/ASR Publication
Recruiting
Ship Recruits
Ship New Lieutenants
Create PEF Obligation
for each Recruit
Training& Education
TIP
School Seat (Quota)
Creation
MOS Manual
TIP Publication
Quota Publication
MOS Manual Changes
Evaulate HRDP Impacts
Circulate Change
Requests
Evaluate M&RA Impacts
MOS Change Analysis
Publish M&RA
Response via MCATS
MOS Manual
Publication
Manpower & Reserve
Affairs
Common User
Processes
Intra-M&RA
Collaboration
Inventory Projection
M&RA
TFSD
TFSD
TFSD
TFSD
TFSD &
OccFldSpnsrs
TFSD &
OccFldSpnsrs
TFSD
MCRC
MCRC
MCRC
Organizational Decisions
HRDP
Structure & Manning
Structure & Manning
Structure & Manning
2
1
2
2
2
TO&E
3
TO&E
ASR
HRDP
Recruiting
Recruiting
3
3
1
2
2
MCRC
TECOM
TECOM
Ship Recruits
HRDP
Training& Education
3
1
2
TECOM
TECOM &
OccFldSpnsrs
TECOM
TECOM
TECOM
TECOM
Training& Education
2
Training& Education
TIP
School Seat (Quota) Creation
MOS Manual
MOS Manual Changes
2
3
3
3
4
TECOM
TECOM
TECOM
Evaulate HRDP Impacts
Evaulate HRDP Impacts
Evaluate M&RA Impacts
5
5
6
TECOM
Evaluate M&RA Impacts
6
TECOM
MOS Manual
3
M&RA
HRDP
1
M&RA
Manpower & Reserve Affairs
2
M&RA
M&RA
Common User Processes
Common User Processes
3
3
86
(starting from an
inventory data set,
which defaults to the
actual inventory at any
given time, make a
long-term projection of
aggregate inventory
characteristics by
specified dimensions Grade & MOS, Grade
MOS & Gender, Grade
MOS &
Inventory Simulation
(starting with an
inventory projection,
produces a detailed
inventory of ficticious
Marines suitable for
input to applicable
software tools such as
Staffing Goals or
Promotion Planning
Inventory Forecast
(starts with current
inventory and makes
high-fidelity near term
forecast by "aging" real
Marine data to support
current FY decision
processes such as
staffing and
promotions)
Data Modification &
Management
Data Modification &
Management
Data Modification &
Management
Data Modification &
Management
Historical Time Series &
Rates
Ad Hoc Reporting &
Data Export for
additional user-defined
M&RA
Common User Processes
3
M&RA
Common User Processes
3
M&RA
Common User Processes
3
M&RA
Common User Processes
3
M&RA
Common User Processes
3
M&RA
Common User Processes
3
M&RA
Common User Processes
3
M&RA
Common User Processes
3
87
analysis - e.g. dump all
the data to excel for
further post processing
not support by
SAS/Cognos ad hoc
report tools
Workflow & Alerts
Workspace
Management
Help & Training - using
help and training to
learn HRDP process and
to learn M&RA
software tools
System Administration
Processes
Harware Provision
Hosting /
Interoperability /
External Security
Data Management
Architecture
External Interfaces
HCI / User Experience /
Internal Security
Manpower Planning
Manpower
Management
Reserve Manpower
Planning
Reserve Manpower
Management
M&RA & TECOM
Collaboration
M&RA & MCRC
Collaboration
M&RA & TFSD
Collaboration
M&RA
Common User Processes
3
M&RA
Common User Processes
3
M&RA
Common User Processes
3
M&RA
M&RA
Manpower & Reserve Affairs
System Administration Processes
2
3
M&RA
M&RA
M&RA
M&RA
System Administration Processes
System Administration Processes
System Administration Processes
System Administration Processes
3
3
3
3
M&RA
MP
System Administration Processes
Manpower & Reserve Affairs
3
2
MM
Manpower & Reserve Affairs
2
RA
Manpower & Reserve Affairs
2
RA
Manpower & Reserve Affairs
2
M&RA - TECOM
HRDP
1
M&RA - MCRC
HRDP
1
M&RA - TFSD
HRDP
1
88
Table 13: Shows the MP Manning Control process space
Business
Process
Process
Owner
Parent Process
HRDP
USMC
Manpower & Reserve Affairs
M&RA
HRDP
Manpower Planning
MPP
Manpower & Reserve Affairs
Manning Controls
MPP-50
Manpower Planning
Input Authorized Enlisted Endstrength
MPP-50
Manning Controls
Forecast Enlisted T2P2
MPP-50
Manning Controls
Forecast Enlisted Initial Accessions
Training
MPP-50
Forecast Enlisted T2P2
Get aggregate accession mission from
Forecast Enlisted Initial
MPP20 (broken out by male/female)
MPP-50
Accessions Training
Calculate bootcamp attrition by days for
male & female using integer math using
historical average from 3 years of history
Forecast Enlisted Initial
(default = last 3 years)
MPP-50
Accessions Training
Rollup in man-year average for
Forecast Enlisted Initial
bootcamp attrition (called boot_out)
MPP-50
Accessions Training
Forecast Enlisted Initial
Import Classification Plan from MPP20
MPP-50
Accessions Training
Forecast Enlisted Initial
Add boot_out = bootcamp attrition
MPP-50
Accessions Training
Compute, over 3 years of data, median
time to train by MOS = (MOS grad date AFADBD) and subtract off 89 days for for
Forecast Enlisted Initial
bootcamp
MPP-50
Accessions Training
For each MOS_i, [Boot_Out_Manyears x
(MOS_i / Total_Class_Plan) x
(MOS_i_time_to_train) / 365] averaged
Forecast Enlisted Initial
over 3 years of class_plan data
MPP-50
Accessions Training
Forecast Enlisted Lateral Move Training
MPP-50
Forecast Enlisted T2P2
legacy = 3 yr forecast into each MOS use time to train from accessions but
Forecast Enlisted Lateral Move
subtract 21 because no MCT
MPP-50
Training
question: why not get lat move forecast
from retention planner?? ANSWER: DO
Forecast Enlisted Lateral Move
IT!!!
MPP-50
Training
Forecast Enlisted Career Level Training
MPP-50
Forecast Enlisted T2P2
filter MARADMINs to get those which
authorize training for Sgt & above
Forecast Enlisted Career Level
(average over 3 years?)
MPP-50
Training
Level
0
1
2
3
4
4
5
6
6
6
6
6
6
6
5
6
6
5
6
89
get maradmin for any training over 20
weeks (if under 20 weeks don't factor
into p2t2)
Forecast Enlisted PCS Move Manyears
3yr average of number x
duration_in_days/365
Forecast Enlisted Patients Manyears
3 year average of end_of_month
snapshots - use as FTE estimate
Forecast Enlisted Prisoners Manyears
same as patients = 3 year average of
end_of_month snapshots - use as FTE
estimate
Input Authorized Officer Endstrength
Forecast Oficer T2P2
Forecast Officer Initial Accessions
Training
Forecast Ground Officer Initial
Accessions Training
Forecast Aviation Officer Initial
Accessions Training
Forecast Adjutant Officer Initial
Accessions Training - need details - get
accession mission from MPP30 - what
about the time to train piece?
Forecast Officer Lateral Move Training
(do officer lat moves exist - i.e. does
accepting career force designation ever
come with an MOS change?)
Forecast Officer Career Level Training
MARADMINs + BOARD RESULTS - PME
CAPT - PME MAJ - PME LTCOL (all 1 yr
fixed length schools)
MARADMINs for NPS & other grad
schools (called officer-other) 100%
bought (ASR = T/O) + 3 or 4 law
programs + MCLEP at PSU (logistics
training - 1month short course?)
Forecast Officer PCS Move Manyears
3yr average of number x
duration_in_days/365
Forecast Officer Patients Manyears
(same as enlisted)
MPP-50
MPP-50
Forecast Enlisted Career Level
Training
Forecast Enlisted T2P2
Forecast Enlisted PCS Move
Manyears
Forecast Enlisted T2P2
Forecast Enlisted Patients
Manyears
Forecast Enlisted T2P2
MPP-50
MPP-50
MPP-50
Forecast Enlisted Prisoners
Manyears
Manning Controls
Manning Controls
MPP-50
MPP-50
MPP-50
MPP-50
MPP-50
6
5
6
5
6
5
6
4
4
MPP-50
Forecast Officer T2P2
Forecast Enlisted Initial
Accessions Training
Forecast Enlisted Initial
Accessions Training
MPP-50
Forecast Enlisted Initial
Accessions Training
6
MPP-50
MPP-50
Forecast Officer T2P2
Forecast Officer T2P2
5
5
MPP-50
Forecast Officer Career Level
Training
6
MPP-50
MPP-50
Forecast Officer Career Level
Training
Forecast Officer T2P2
Forecast Officer PCS Move
Manyears
MPP-50
Forecast Officer T2P2
MPP-50
MPP-50
5
6
6
6
5
6
5
90
3 year average of end_of_month
snapshots - use as FTE estimate
Forecast Officer Prisoners Manyears
(same as enlisted)
same as patients = 3 year average of
end_of_month snapshots - use as FTE
estimate
Publish Manning Controls
MPP-50
Forecast Officer Patients
Manyears
6
MPP-50
Forecast Officer T2P2
5
MPP-50
MPP-50
Forecast Officer Prisoners
Manyears
Manning Controls
6
4
Table 14: Shows the MP Target Force process space
Business
Process
Process
Owner
Parent Process
HRDP
USMC
Manpower & Reserve Affairs
M&RA
HRDP
Manpower Planning
MPP
Manpower & Reserve Affairs
Tgt Force Planning
MPP50
Manpower Planning
GAR
MPP50
Tgt Force Planning
Import Manning Controls (End Srength &
T2P2)
GAR
Import MOS Manual/Update MOS Defs
GAR
Import ASR
MPP50
GAR
MSR edit
MPP50
GAR
Map B-Billets
MPP50
MSR edit
Map Necessary & Exception Billets
MPP50
Map B-Billets
Import/Compute N+E B-Map (BMOS w/
Necessary target = single PMOS resides in
MPP50 dataset & in most cases already
shows necessary PMOS in ASR but not
aways; BMOS w/ Necessary target =
group of allowable PMOS then fairshare
over group based on proportions of
PMOS in group specified in A +
necessary_B_that_have
Map Necessary & Exception
unique_target_PMOS)
MPP50
Billets
Apply N+E B-map (automated search and
Map Necessary & Exception
replace)
MPP50
Billets
Map Free B-Billets
MPP50
Map B-Billets
Manage/Edit list of exclusion MOS
Map Free B-Billets
Manage/Edit list of exclusion MOS
Map Free B-Billets
For each MOS_Grade_Pair_i, compute,
using integer math, fair_share_i =
total_count(A + Necessary B billets
MPP50
Map Free B-Billets
Level
0
1
2
3
4
5
5
5
5
6
7
8
8
7
8
8
8
91
requiring MOS_Grade_Pair_i) /
total_count(A + Necessary B billets for
that Grade); NOTE: necessary means
Necessary as defined by MOS manual +
those defined as Exception (meaning
there are exceptional billets where a
particular PMOS is necessary) AND the
billet in question is one of the exceptions
where the PMOS is necessary (the
musician at 6 particular recruiting
stations where auditions are held, or
Marine Corps Security Guard billets)
Randomly map fair_share_i of free bbillets to MOS_Grade_Pair_i
Optionally adjust to over-ride fair_share
logic by editing and/or recalling saved
free b-billet map
Save free b-billet map to dataset for
future use
Import/Edit DOPMA/Top6 Constraints
compute integer grade constraints from
input end strength using (top 1, top 2,
and top 6 percentages) for enlisted or
DOPMA percentages for officers
Import/Edit NAR Limits (constraints on
reduction/increase of any Grade,MOS, or
Grade-MOS pair in deriving NAR from
MSR
Import/Edit GAR Limits (constraints on
reduction/increase of any Grade,MOS, or
Gr-MOS pair in deriving GAR from NAR)
Compute NAR algorithm (add back T2P2
to get ASR + T2P2 = endstrength ->
ignores grade constraintsMSR/NAR
controls); if MSR+T2P2 < Endstrength,
then add billets via fair_share,
constrained by )
Compute GAR algorithm (adjust NAR at
each grade/MOS to get GAR by applying
grade constraints from highest grade
down to lowest and approximately
fair_sharing increases/reductions except
as constrained by NAR/GAR controls and
affected by skill family logic - ask DSAI for
MPP50
Map Free B-Billets
8
MPP50
Map Free B-Billets
8
MPP50
MPP50
Map Free B-Billets
GAR
8
5
MPP50
Import/Edit DOPMA/Top6
Constraints
6
MPP50
GAR
5
MPP50
GAR
5
MPP50
GAR
5
MPP50
GAR
5
92
precise algorithm)
Review/Analyze GAR - Workflow =
MPP20 & MPP30
Publish GAR - Workflow = MPP20 &
MPP30
Optimize Path to Achieve GAR
Tgt Force Ad Hoc Analysis
MPP50
GAR
5
MPP50
MPP50
MPP50
GAR
Tgt Force Planning
Tgt Force Planning
5
4
4
Table 15: Shows the MP Officer Inventory Plan process space
Business Process
Process
Owner
Parent Process
HRDP
USMC
Manpower & Reserve Affairs
M&RA
HRDP
Manpower & Reserve
Manpower Planning
MPP
Affairs
Officer Inventory Plan
MPP-30
Manpower Planning
Officer Endstrength Accounting
MPP-30
Officer Inventory Plan
MPP-30 / Maj Darby
Officer Endstrength
Get TFDW snapshot once/month Wiler
Accounting
Compare to previous month
MPP-30 / Maj Darby
Officer Endstrength
snapshot
Wiler
Accounting
MPP-30 / Maj Darby
Officer Endstrength
Compute Gains & Losses
Wiler
Accounting
Sort Gains & Losses into
MPP-30 / Maj Darby
Officer Endstrength
Categories
Wiler
Accounting
capture promote-out and
MPP-30 / Maj Darby
Sort Gains & Losses into
promote-in by SSN
Wiler
Categories
drill down to individual records
to investigate invalid separation
MPP-30 / Maj Darby
Sort Gains & Losses into
(sep) codes
Wiler
Categories
MPP-30 / Maj Darby
Officer Endstrength
Forecast to Sep 30
Wiler
Accounting
MPP-30 / Maj Darby
Officer Endstrength
Compare to plan/forecast
Wiler
Accounting
MPP-30 / Maj Darby
Officer Endstrength
Publish End Strength Report
Wiler
Accounting
create aggregate report (how
MPP-30 / Maj Darby
Publish End Strength
actuals are tracking to plan)
Wiler
Report
circulate via workflow = MPP MPP-30 / Maj Darby
Publish End Strength
MP - D.C. M&RA
Wiler
Report
Forecast Future promotion
MPP-30 / Maj Darby
Officer Endstrength
requirement
Wiler
Accounting
extract promotion numbers
MPP-30 / Maj Darby
Forecast Future
Leve
l
0
1
2
3
4
5
5
5
5
6
6
5
5
5
6
6
5
6
93
generated in intermediate
calculations in the inventory
accession/retention planning
based on flow points,
opportunities & statutory&policy
limits
publish promotion forecast to
workflow = MMPR
publish fitrep forecast to
workflow = MMSB
Officer Budget Reporting
compute budget based on
inventory tracking
Compare to forecast
input saved forecast (legacy =
spreadsheet?)
compute comparison by grade
(by MOS upon request)
Publish Budget Report
create detailed report
circulate via workflow = MPP40
Officer Inventory Analysis
MOS status reports
compare A + Necessary B billets
in the GAR to actual inventory by
grade & MOS
Unrestricted Officer Inventory
Plan
Unrestricted Officer Promotion
Planning
Forecast Vacancies
Forecast Continuation by Grade
& MOS; continuation = 1 - (total
attrition); total attrition =
statutory & voluntary
retirements (voluntary only
consider w/in 90 days or less of
board convene date but
Wiler
promotion requirement
MPP-30 / Maj Darby
Wiler
MPP-30 / Maj Darby
Wiler
MPP-30
MPP-30 / Maj Darby
Wiler
MPP-30 / Maj Darby
Wiler
MPP-30 / Maj Darby
Wiler
MPP-30 / Maj Darby
Wiler
MPP-30 / Maj Darby
Wiler
MPP-30 / Maj Darby
Wiler
MPP-30 / Maj Darby
Wiler
MPP-30
MPP-30 / Maj Darby
Wiler
Forecast Future
promotion requirement
Forecast Future
promotion requirement
Officer Inventory Plan
6
6
4
Officer Budget Reporting
5
Officer Budget Reporting
5
Compare to forecast
6
Compare to forecast
6
Officer Budget Reporting
5
Publish Budget Report
6
Publish Budget Report
Officer Inventory Plan
6
4
Officer Inventory Analysis
5
MOS status reports
6
4
MPP-30
Officer Inventory Plan
Unrestricted Officer
Inventory Plan
Unrestricted Officer
Promotion Planning
MPP-30
Forecast Vacancies
7
MPP-30 / Maj Darby
Wiler
MPP-30
MPP-30 / Maj Koch
5
6
94
retirement 91 days after board
convene makes you eligible) +
deaths + voluntary EAS
separation + separation induced
by promtion plan opportunity
rates + promote outs to next
grade; legacy is weighted
average of N years of history;
user chooses (not necessarily
continguous) history years and
weights)
Forecast Inventory for 1 year out
by starting w/ current inventory
and applying continuation rate
using integer math by MOS &
Grade
Forecast inventory for each
subsequent FY by starting with
previous FY forecast inventory,
applying previous FY promotion
plan assuming that for all MOS
selection rate = integer
approximation of planned
opportunity rate, then applying
forecast continuation
Forecast Vacancies by FY =
Target Force (FY) - Forecast
Inventory (FY)
Optimize Officer Promotion
Eligibility Zones
Input statutory limits = max time
in service if passed over twice =
06/30 05/28 04/20
03/pass_date+7mo
02/pass_date+7mo
Input and edit authorized
strength
Input General Officer vacancies =
forecast of 06 losses via promote
out - data comes from MMSL
Input attrition override provides granular control over
continuation rate; accepts by
month time series [[[ NOT USED LOW PRIORITY ]]]
MPP-30
Forecast Vacancies
7
MPP-30
Forecast Vacancies
7
MPP-30
Forecast Vacancies
Unrestricted Officer
Promotion Planning
7
MPP-30
6
MPP-30
Optimize Officer
Promotion Eligibility Zones
Optimize Officer
Promotion Eligibility Zones
MPP-30
Optimize Officer
Promotion Eligibility Zones
7
MPP-30
Optimize Officer
Promotion Eligibility Zones
7
MPP-30
7
7
95
Input Promotion Board results over-rides promotion piece of
first year forecast to reflect
promotion results not yet visible
in TFDW - data source can be
either be last year's promotion
plan that was executed or info
from MMPR who executed the
plan, and normally executes it
exactly according to plan but
there are exceptions - an
interface to enter this data by
hand or to upload it form excel is
fine
FOR EACH FY for EACH GRADE
Input any of: (# selections, zone
size, opportunity, flow point) and
solve for dependent values
based on entered values (flow
point is estimate based on IZ
inventory) ;
Pull Inventory for computed (or
input) zone and review/adjust
(e.g. if computed zone requires
splitting group with same date of
rank, then adj zone and re-run
with input zone size to solve for
opportunity, flow point)
Forecast MOS health / PRECEPT
requirements
forecast promotion plan
execution assuming that every
MOS receives promotions as
close to the planned opportunity
rate as possible w/ integer math
At each Grade, precept required
for any MOS forecast to be less
than 100% of total A billets plus
+ necessary B billets in Target
Force
Assemble/Format Output for
Unofficial Review
table , text - re-use & edit - same
verbiage surrrounds table but
with slight mods
MPP-30
Optimize Officer
Promotion Eligibility Zones
7
MPP-30
Optimize Officer
Promotion Eligibility Zones
7
MPP-30
Optimize Officer
Promotion Eligibility Zones
Unrestricted Officer
Promotion Planning
MPP-30
Forecast MOS health /
PRECEPT requirements
MPP-30
MPP-30
Forecast MOS health /
PRECEPT requirements
Unrestricted Officer
Promotion Planning
MPP-30
Assemble/Format Output
for Unofficial Review
MPP-30
7
6
7
7
6
7
96
Collaborate w/ MMPR on
unofficial review
Circulate through official
approval flow
Forward approved plan to
MMPR for execution
Unrestricted Officer Promotion
Planning Reporting & Analysis
Unrestricted Officer Promotion
Planning Analysis
Input default opportunity rates
by grade by in-zone/above-zone
- defaults mean manager can
edit isolated instances by grade
and year and default applies
elsewhere
solve for career designation rate
by officer cat (eg gnd cmbt arms,
gnd cmbt sppt, aviation,lawyer)
based on holding flow point
constant at 4yrs to capt & setting
aviation,lawyers career design at
100%
Unrestricted Officer Retention
Bonus Planning (Aviation Only)
Import 6-yr-out tgt force (GAR)
6 yrs from earning wings usually
equals 8 years from initial
contract = end of initial
commitment
need to forecast continuation
rates as a function of bonus - 6
yrs in the future this is a
challenge!
in practice, there are some who
won't stay no matter what
bonus, and some who will stay
no matter what bonus, or not need to optimize bonus to meet
requirement
legacy = spreadsheet - possible
PSU study to develop model
MPP-30
Unrestricted Officer
Promotion Planning
Unrestricted Officer
Promotion Planning
Unrestricted Officer
Promotion Planning
Unrestricted Officer
Promotion Planning
Unrestricted Officer
Promotion Planning
MPP-30
Unrestricted Officer
Promotion Planning
Analysis
MPP-30
MPP-30
MPP-30
MPP-30
6
6
6
6
6
7
MPP-30 / Capt Chris
Davidson
Unrestricted Officer
Promotion Planning
Analysis
Unrestricted Officer
Inventory Plan
Unrestricted Officer
Retention Bonus Planning
(Aviation Only)
MPP-30 / Capt Chris
Davidson
Import 6-yr-out tgt force
(GAR)
7
MPP-30 / Capt Chris
Davidson
Unrestricted Officer
Retention Bonus Planning
(Aviation Only)
6
MPP-30 / Capt Chris
Davidson
MPP-30 / Capt Chris
Davidson
Unrestricted Officer
Retention Bonus Planning
(Aviation Only)
Unrestricted Officer
Retention Bonus Planning
MPP-30
MPP-30 / Capt Chris
Davidson
7
5
6
6
6
97
Unrestricted Officer
Accession/Retention Planning
Compute Aggregate Ground
Officer Accession/Retention
Mission (YGSS)
Input Target Force - ideally 10
years out to tgt major but GAR
only goes out 7 so current
process uses whatever year is
believed to best represent the
10-yr out requirement
Import/Edit desired flow points,
opportunities (in-zone, below
zone, above zone) and statutory
& policy limits (retention plan is
implicit in opportunity for career
force designation)
Input attrition/continuation
rates (or link to model as YGSS
does)
Reverse engineer input
accessions that yield tgt after
flow via
promotion/attrition/continuatio
n is modeled (YGSS does this)
repeat process with different
career designation opportunity
to optimize retention
Compute Ground Officer
Accession/Retention Mission by
MOS (YGSS)
Publish Aggregate Ground
Officer Accession Mission
(workflow)
Compute Aggregate Aviator
Accession/Retention Mission
(YGSS)
repeat aggregate process but
make flow points, opportunities
& continuation rates pilot
specific check MOS totals against
MPP-30
(Aviation Only)
Unrestricted Officer
Inventory Plan
Unrestricted Officer
Accession/Retention
Planning
MPP-30
Compute Aggregate
Ground Officer
Accession/Retention
Mission (YGSS)
MPP-30 / Maj Darby
Wiler
MPP-30
MPP-30
Compute Aggregate
Ground Officer
Accession/Retention
Mission (YGSS)
Compute Aggregate
Ground Officer
Accession/Retention
Mission (YGSS)
MPP-30
Compute Aggregate
Ground Officer
Accession/Retention
Mission (YGSS)
Compute Aggregate
Ground Officer
Accession/Retention
Mission (YGSS)
Unrestricted Officer
Accession/Retention
Planning
Unrestricted Officer
Accession/Retention
Planning
Unrestricted Officer
Accession/Retention
Planning
MPP-30
Compute Aggregate Pilot
Accession/Retention
Mission (YGSS)
MPP-30
MPP-30
MPP-30
MPP-30
5
6
7
7
7
7
7
6
6
6
7
98
aggregate plan
compute bonuses to achieve
retention mission
Publish Aggregate Aviator
Accession/Retention Mission (fill
in workflow here - must go to
Capt Davidson for bonus
computations)
Davidson to Wiler to Jeppe ->
same as Ground
MPP-30
MPP-30
MPP-30
Create TIP request
MPP-30
sum new accession mission by
MOS, considering attrition and
fiscal year roll-over / need feeder
MOS data for this
MPP-30
Publish TIP request (fill in
workflow here)
submit at TIP conference
(informal collab w/ FSTB TECOM
- formal schools training branch)
New Lieutenant Distribution
import school quota data (must
be editable for overfiill)
forecast TBS data (numbers, not
names) based on MCRC flow +
attrition model
import MOS tgts from inventory
plan
manually input constraints such
as min to each MOS from each
class
solve LP to minimize time
awaiting training
Publish New Lieutenant
MPP-30
MPP-30
MPP-30
MPP-30
MPP-30
MPP-30
MPP-30
MPP-30
MPP-30
Compute Aggregate Pilot
Accession/Retention
Mission (YGSS)
Unrestricted Officer
Accession/Retention
Planning
Publish Aggregate Aviator
Accession/Retention
Mission (fill in workflow
here - must go to Capt
Davidson for bonus
computations)
Unrestricted Officer
Accession/Retention
Planning
Create TIP request
Unrestricted Officer
Accession/Retention
Planning
Publish TIP request (fill in
workflow here)
Unrestricted Officer
Accession/Retention
Planning
New Lieutenant
Distribution
New Lieutenant
Distribution
New Lieutenant
Distribution
New Lieutenant
Distribution
New Lieutenant
Distribution
Unrestricted Officer
7
6
7
6
7
6
7
6
7
7
7
7
7
6
99
Distribution
to TBS MMOA5 MMOA2 OccFld
Sponsors
Unrestricted Officer
Accession/Retention Track
Actuals to Plans
Unrestricted Officer
Accession/Retention Ad hoc
Analysis
ad hoc analysis regarding officer
accessions/career force
designation, continuation rates,
budget implications, etc etc
Restricted Officer Inventory Plan
LDO Inventory Plan
Compute LDO Vacancies
Pull ASR Data (not a mistake!
LDO keys off ASR - not GAR!)
(though GAR = ASR is usually
true for LDO and always true for
WO)
Pull ODSE/TFDW Inventory Data
including retirement &
promotion data
Edit Retirement Data per
OCCFLD Sponsor Input -> creates
private version of inventory data
for use in this program
Compute LDO Vacancies by
Grade Top Down = ASR - (Inv Retirements - Promotions)
Determine LDO Zones/Eligible
Inventory by grade by choosing
integer # that lies within
competition rate recommended
by SECNAV INSTR 1412.09B and
adHERES TO TIME IN GRADE &
ALSO 3 YRS TIG FOR IN ZONE
Determine LDO Accession Plan
by choosing integer # of W2,W3
to promote to O3 that lies within
competition rate recommended
MPP-30
Accession/Retention
Planning
Publish New Lieutenant
Distribution
Unrestricted Officer
Accession/Retention
Planning
Unrestricted Officer
Accession/Retention
Planning
MPP-30
MPP-30
MPP-30 / Maj Brad
Davin
MPP-30
Unrestricted Officer
Accession/Retention Ad
hoc Analysis
Officer Inventory Plan
Restricted Officer
Inventory Plan
LDO Inventory Plan
MPP-30
Compute LDO Vacancies
7
MPP-30
Compute LDO Vacancies
7
MPP-30
Compute LDO Vacancies
7
MPP-30
Compute LDO Vacancies
7
MPP-30
LDO Inventory Plan
6
MPP-30
LDO Inventory Plan
6
MPP-30
MPP-30
7
6
6
7
4
5
6
100
by SECNAV INSTR 1412.09B and
addresses any MOS health issues
Informal collaboration w/ OccFld
Sponsors for sanity check on
plans
LDO Promotion & Accession
Decision
Storage/Versioning/Workflow/Al
erts = SEE SRS d.3.5 Internal Data
Requirements
LDO Promotion Output: decision
= list of eligible Marines +
metrics = competition rate,
lineage data
WO Inventory Plan
Compute WO Vacancies
Pull ASR/GAR Data
Pull ODSE/TFDW Inventory Data
including retirement &
promotion data
Edit Retirement Data per
OCCFLD Sponsor Input
Compute by Grade Vacancies
Down Top = ASR/GAR - (Inv Retirements - Promotions)
Determine WO Zones/Eligible
Inventory by MOS by choosing
integer # that lies within
competition rate recommended
by SECNAV INSTR 1412.09Band
addresses any MOS health issues
2 YRS TIG FOR IN ZONE - 3YRS TO
PIN IT ON
Determine WO Accession Plan by
choosing integer # of E5 - E7 to
promote to WO that lies within
competition rate recommended
by SECNAV INSTR 1412.09B
WO Promotion & Accession
Decision
Storage/Versioning/Workflow/Al
erts = SEE SRS d.3.5 Internal Data
Requirements
MPP-30
LDO Inventory Plan
6
MPP-30
LDO Inventory Plan
6
MPP-30
MPP-30 / Maj Brad
Davin
MPP-30
MPP-30
LDO Inventory Plan
Restricted Officer
Inventory Plan
WO Inventory Plan
Compute WO Vacancies
6
MPP-30
Compute WO Vacancies
7
MPP-30
Compute WO Vacancies
7
MPP-30
Compute WO Vacancies
7
MPP-30
WO Inventory Plan
6
MPP-30
WO Inventory Plan
6
MPP-30
WO Inventory Plan
6
5
6
7
101
WO Promotion Output: decision
= list of eligible Marines +
metrics = competition rate,
lineage data
MPP-30
WO Inventory Plan
6
Table 16: Shows the MP Enlisted Inventory Plan process space
Process
HRDP
Manpower & Reserve Affairs
Business Process Owner
USMC
M&RA
Manpower Planning
Enlisted Inventory Plan
MPP
MPP-20
Enlisted Promotion Planning
MPP-20
E1 to E2 Promotions (Monthly)
Mr. Lane Beindorf
E1 to E2 Promotions
automatic in MCTFS at local CMD
by Time in Service / Time Grade
Requirements doesn't flow
through m&ra
E3-E4 & E4-E5 Promotions
(Monthly)
Compute E3-E4, E4-E5 Vacancies
by MOS
Import GAR (must choose which FY
- current for E3-E4, E4-E5)
Pull ODSE/TFDW Inventory Data
including EAS & promotion data &
composite score
Forecast Inventory one month out
because promotions happen each
month, so only substract EAS and
promotions
Vacancies = GAR minus Inventory
Forecast by MOS
Determine Eligible Inventory by
MOS
take top k composite scores where
k = # of vacancies, if tie, promote
extra
Publish E3-E4, E4-E5 Promotion
Mr. Lane Beindorf
Mr. Lane Beindorf
Parent Process
HRDP
Manpower & Reserve
Affairs
Manpower Planning
Enlisted Inventory
Plan
Enlisted Promotion
Planning
E1 to E2 Promotions
(Monthly)
Mr. Lane Beindorf
E1 to E2 Promotions
Enlisted Promotion
Planning
E3-E4 & E4-E5
Promotions (Monthly)
Compute E3-E4, E4-E5
Vacancies by MOS
Mr. Lane Beindorf
Compute E3-E4, E4-E5
Vacancies by MOS
Mr. Lane Beindorf
Mr. Lane Beindorf
Mr. Lane Beindorf
Compute E3-E4, E4-E5
Vacancies by MOS
Compute E3-E4, E4-E5
Vacancies by MOS
E3-E4 & E4-E5
Promotions (Monthly)
Mr. Lane Beindorf
Mr. Lane Beindorf
Determine Eligible
Inventory by MOS
E3-E4 & E4-E5
Mr. Lane Beindorf
Mr. Lane Beindorf
Leve
l
0
1
2
3
4
5
6
7
5
6
7
7
7
7
6
7
6
102
Candidates
send cutting scores to MMPR = list
(MOS, cutting score) for all MOS
(MMPR puts on website w/in 24
hours & enters in MCTFS generates
list of Marines for each
commander)
Enlisted Promotion Output:
decision = list of eligible Marines +
metrics = opportunity rate, lineage
data for eligible population
E5-E6...E8-E9 Promotions
(Monthly)
Compute E6-E9 allocations by MOS
for E5-E8 Promotion
Forecast Inventory
Pull ODSE/TFDW Inventory Data
including EAS, promotion
selections
forecast EAS attrition for each
OccFld/Grade to avoid small cell
size of MOS/Grade
forecast NEAS attrition from
history data - also by OccFld &
grade to avoid small cell size usually 3% - include losses to WO
ranks
forecast compare EAS forcast to
actual retirements declared in the
inventory data and use the larger
of the two
collaborate with OccFld sponsors
for sanity check on forecast
Compute by Grade Allocations
Down Top = GAR - (Inv Retirements - Promotions to next
grade)
Determine Zones of Eligible
Inventory by MOS
select (filter) inventory forecast
down to those who (will) meet the
minimum time_in_grade
Promotions (Monthly)
Mr. Lane Beindorf
Publish E3-E4, E4-E5
Promotion Candidates
7
Mr. Lane Beindorf
Publish E3-E4, E4-E5
Promotion Candidates
Enlisted Promotion
Planning
E5-E6...E8-E9
Promotions (Monthly)
Compute E6-E9
allocations by MOS
for E5-E8 Promotion
Mr. Lane Beindorf
Forecast Inventory
8
Mr. Lane Beindorf
Forecast Inventory
8
Mr. Lane Beindorf
Forecast Inventory
8
Mr. Lane Beindorf
Forecast Inventory
8
Mr. Lane Beindorf
Forecast Inventory
8
Mr. Lane Beindorf
Mr. Lane Beindorf
Mr. Lane Beindorf
Mr. Lane Beindorf
Mr. Lane Beindorf
Mr. Lane Beindorf
Compute E6-E9
allocations by MOS
for E5-E8 Promotion
E5-E6...E8-E9
Promotions (Monthly)
Determine Zones of
Eligible Inventory by
MOS
7
5
6
7
7
6
7
103
requirement (across all MOS)
remove all those whose draw case
code indicates they have been
passed over for promotion (and
hence are above zone)
remove the youngest 50% (by
time_in_grade) of remaining
forecast - and compute average
_grade_eligible_YOS (year of
service) for remaining oldest 50%
across all MOS
Mr. Lane Beindorf
Mr. Lane Beindorf
repeat eligible_YOS calculation for
each MOS individually
Mr. Lane Beindorf
compare eligible_YOS for each
MOS to grade_eligible YOS -> if > +
1yr, flag slow_promoting_MOS, if <
- 1yr, flag fast promoting MOS
Mr. Lane Beindorf
if fast_promoting_MOS, set tgt
opportunity = sevnav
recommendation + 10%, if
slow_promoting_MOS, set
opportunity = sevnav
recommendation - 10%, else set
opportunity = exactly sevnav
recommendation
Mr. Lane Beindorf
choose integer # closest to desired
opportunity
90 days advance - circulate to
OccFld sponsors
60 days advance - redo everything
and circulate to MMPR - MMPR
publishes via naval msg to give
heads up on to all eligible
30 days advance - redo everything
and circulate to MMPR as final
eligible list - MMPR publishes via
naval msg and forms board
after each board meets, starting
with E9, adjust next down grade by
moving lower zone boundary cannot change total list of eligibles
Determine Zones of
Eligible Inventory by
MOS
Determine Zones of
Eligible Inventory by
MOS
Determine Zones of
Eligible Inventory by
MOS
Determine Zones of
Eligible Inventory by
MOS
7
7
7
7
Mr. Lane Beindorf
Determine Zones of
Eligible Inventory by
MOS
Determine Zones of
Eligible Inventory by
MOS
Determine Zones of
Eligible Inventory by
MOS
Mr. Lane Beindorf
Determine Zones of
Eligible Inventory by
MOS
7
Mr. Lane Beindorf
Determine Zones of
Eligible Inventory by
MOS
7
Mr. Lane Beindorf
Determine Zones of
Eligible Inventory by
MOS
7
Mr. Lane Beindorf
7
7
7
104
- only move between in_zone and
below_zone - especially after E9
cause many forceouts if passed;
and also E6 because lateral moves
can result in a person in a new
MOS with an unusually high or low
time_in_grade/YOS compared to
their new MOS so people manually
put in_zone even if lineal numbers
out of sequence
Track actuals to forecast and
authorize promotions month by
month
after boards meet and selects
people at each grade, MOS then
MPP-20 tracks how many forecast
vacancies are actually realized
each month and notifies MMPR of
how many more to promote (by
grade only in order of seniority)
each month
Enlisted Promotion & Accession
Decision
Storage/Versioning/Workflow/Aler
ts = SEE SRS d.3.5 Internal Data
Requirements
Enlisted Promotion Output:
decision = list of eligible Marines +
metrics = OPPORTUNITY rate,
lineage data
Mr. Lane Beindorf
E5-E6...E8-E9
Promotions (Monthly)
6
Mr. Lane Beindorf
Track actuals to
forecast and
authorize promotions
month by month
7
Mr. Lane Beindorf
E5-E6...E8-E9
Promotions (Monthly)
6
Enlisted Retention Planning
MPP-20
First Term Alignment Plan (FTAP)
Capt Paul Bock
Inventory Forecast & Sort
Pull ODSE "aged" Snapshot = who
will have 5 - 18.5 YOS as of end
next FY
filter on ECC (end current contract)
and account for early re-enlistment
opportunities
Sort by YOS zones - A [1.5, 6) B [6,
10) C [10, 14) D [14, 18) E [18, 20)
SE [20, 30)
Capt Paul Bock
E5-E6...E8-E9
Promotions (Monthly)
Enlisted Inventory
Plan
Enlisted Retention
Planning
First Term Alignment
Plan (FTAP)
Capt Paul Bock
Inventory Forecast &
Sort
7
Capt Paul Bock
Inventory Forecast &
Sort
7
Capt Paul Bock
Inventory Forecast &
Sort
7
Mr. Lane Beindorf
6
4
5
6
105
Import Tgt Force (GAR - currently
use 3 yr out for FTAP)
Capt Paul Bock
First Term Alignment
Plan (FTAP)
First Term Alignment
Plan (FTAP)
First Term Alignment
Plan (FTAP)
First Term Alignment
Plan (FTAP)
First Term Alignment
Plan (FTAP)
First Term Alignment
Plan (FTAP)
Capt Paul Bock
First Term Alignment
Plan (FTAP)
Capt Paul Bock
Compute Vacancies
GAR - Inv Forecast by Zone &
PMOS (FTAP for zone A only)
Import Bonus Take Rate Forecast
by zone & MOS(CNA)
Identify LAT move MOS = retention
requirement > 40% of eligible
Import/edit Bonus Budget
Constraint (from MPP-40)
Import/Edit success_criteria(MOS)
for each problem MOS that is
virtually impossible to fill
regardless of budget
Optimize Bonus Allocations via LP
= min Z subj to (sum_of_bonuses
<= budget) and (forecast shortage
<= Z for all non-problem MOS's)
and (forecast shortage <=
success_criteria(MOS) for all
problem MOS's)
Informal Review by Stakeholders
(see workflow)
Allocate Mission across Major
Subordinate Commands (MSC)
MOS_tgt(MSC_i,Zone) =
MOS_tgt(Zone) x
MOS_On_Board(MSC_i,Zone) /
MOS_total(Zone) [rounded so as to
minimize the maximum deviation
from the ideal fractional allocation]
[all 5 Zones or just Zone = FTAP or
STAP]
Capt Paul Bock
Publish FTAP (see workflow)
workflow = MPP-20 to MPP to MP
to DC M&RA (sometimes to CMC)
to MMEA6 for execution
log official decision data with
inputs captured
Subsequent Term Alignment Plan
(STAP)
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
First Term Alignment
Plan (FTAP)
First Term Alignment
Plan (FTAP)
First Term Alignment
Plan (FTAP)
Allocate Mission
across Major
Subordinate
Commands (MSC)
First Term Alignment
Plan (FTAP)
Publish FTAP (see
workflow)
Publish FTAP (see
workflow)
Enlisted Retention
Planning
6
6
7
6
6
6
6
6
6
6
7
6
7
7
5
106
Inventory Forecast & Sort
Pull ODSE "aged" Snapshot = who
will have 5 - 18.5 YOS as of end
next FY
filter on ECC (end current contract)
and account for early re-enlistment
opportunities
Sort by YOS zones - A [1.5, 6) B [6,
10) C [10, 14) D [14, 18) E [18, 20)
SE [20, 30)
Import Tgt Force (GAR - currently
use 2 yr out for STAP)
Capt Paul Bock
Subsequent Term
Alignment Plan (STAP)
Capt Paul Bock
Inventory Forecast &
Sort
7
Capt Paul Bock
Inventory Forecast &
Sort
7
Compute Vacancies
GAR - Inv Forecast by Zone &
PMOS (STAP zone B,C,D only)
continuation rates must reflect
enlisted career force controls
which are policies like make E6 by
12 yrs or get out - current policy
allows all comers to re-enlist
Import Bonus Take Rate Forecast
by zone & MOS
Identify LAT move MOS = retention
requirement > 40% of eligible
(zone B only)
Import Bonus Budget Constraint
(from MPP-40)
Import/Edit success_criteria(MOS)
for each problem MOS that is
virtually impossible to fill
regardless of budget
Optimize Bonus Allocations via LP
= min Z subj to (sum_of_bonuses
<= budget) and (forecast shortage
<= Z for all non-problem MOS's)
and (forecast shortage <=
success_criteria(MOS) for all
problem MOS's)
Informal Review by Stakeholders
(see workflow)
Allocate Mission across Major
Subordinate Commands (MSC)
Capt Paul Bock
Inventory Forecast &
Sort
Subsequent Term
Alignment Plan (STAP)
Subsequent Term
Alignment Plan (STAP)
Capt Paul Bock
Compute Vacancies
7
Capt Paul Bock
Compute Vacancies
Subsequent Term
Alignment Plan (STAP)
7
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Subsequent Term
Alignment Plan (STAP)
Subsequent Term
Alignment Plan (STAP)
Capt Paul Bock
Subsequent Term
Alignment Plan (STAP)
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Capt Paul Bock
Subsequent Term
Alignment Plan (STAP)
Subsequent Term
Alignment Plan (STAP)
Subsequent Term
Alignment Plan (STAP)
6
7
6
6
6
6
6
6
6
6
6
107
Publish STAP (see workflow)
workflow = MPP-20 to MPP to MP
to DC M&RA (sometimes to CMC)
to MMEA6 for execution
log official decision data with
inputs captured
Capt Paul Bock
Enlisted Accession Planning
MPP-20
Enlisted Endstrength Planning
End Strength Monthly Accounting
& Reaction
Aggregate Accession Mission =
Authorized End Strength - (Actual
Begin Strength - Losses +
NonAccession Gains)
Maj Adam Jeppe
Losses = EAS + NonEAS
Maj Adam Jeppe
EAS = EAS Inventory - retention
plan (FTAP/STAP/SE)
Maj Adam Jeppe
Capt Paul Bock
Capt Paul Bock
Maj Adam Jeppe
Maj Adam Jeppe
NonEAS = forecast (currently based
on history)
Maj Adam Jeppe
NonAccession Gains = E to O +
Returning Deserters + EAD
recruiter gains (extended active
duty reservists hired by recruiters
to help recruiting)
Maj Adam Jeppe
Returning Deserters count against
strength pending legal action
E to O includes OCC students who
are temporarily E5 while in school 3 classes per year 3 months each
retirement forecast should depend
on eligble population - not just
historical weighted ave (typically
50% of declared retirements)
catch direct discharge = ship &
discharge so fast that they show up
as a gain and a loss in the same
Maj Adam Jeppe
Maj Adam Jeppe
Maj Adam Jeppe
Maj Adam Jeppe
Subsequent Term
Alignment Plan (STAP)
Publish STAP (see
workflow)
Publish STAP (see
workflow)
Enlisted Inventory
Plan
Enlisted Accession
Planning
Enlisted Endstrength
Planning
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
6
7
7
4
5
6
7
7
7
7
7
7
7
7
7
108
monthly snapshot of TFDW creates data discrepancy between
MP & MCRC
EAS losses hardest to forecast takes retention plan as input (E6 to
E9: STAP / E4 - E5, some E3: FTAP;
cross-yr extensions throw off end
strength accounting/forecast (in-yr
extensions do not) (medical,
deployment, etc)
output (endstrength and gains and
losses) from plan vs actuals AND
any adjustment to the plan
POSSIBLE ACTIONS: EARLY
PROGRAM, ADJ ACCESSSION
MISSION, OTHER CONTROLS TO
BRING STRENGTH CLOSER TO
TARGET
Maj Adam Jeppe
Maj Adam Jeppe
Maj Adam Jeppe
Budget Report (monthly) (for MPP40)
Maj Adam Jeppe
output - agg endstrength by grade
by month - gains, losses,
Maj Adam Jeppe
enter actual endstrength for
current month (TFDW)
enter actual gains & losses by
grade by sex by eo, ead, rd,
continous re-enlistments, other for
current month (TFDW)
reverse engineer monthly details
based on updates to actuals &
plans on the aggreate/annual level
Maj Adam Jeppe
Maj Adam Jeppe
Maj Adam Jeppe
End Strength Report (monthly
output) for MP/DCM&RA
Maj Adam Jeppe
continuation rate averaged over 3
years based on YOS
Maj Adam Jeppe
End Strength Report (monthly)
End Strength Report (monthly)
Maj Adam Jeppe
Maj Adam Jeppe
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
Accounting &
Reaction
End Strength Monthly
7
7
7
7
7
7
7
7
7
7
7
7
109
Accounting &
Reaction
Enlisted Endstrength
Planning
Enlisted Accession
Mission
Enlisted Accession
Mission
Enlisted Accession
Mission
Enlisted Accession Mission
same as monthly analysis except
easier to forecast on annual level
input FTAP & STAP & current
endstrength
Maj Adam Jeppe
updates based on ytd progress
outputs: accession mission +
monthly forecast based on phasing
(FMAM, JJAS, SONDJ)
End Strength Analysis (ad hoc on
demand)
solve for aggregate accession
mission based on retention & end
strength
solve for aggregate retention
mission based on accession & end
strength
solve for end strength based on
retention & accession
T2P2 analysis = compute "Big T": =
training manyears for T2P2 input
to Manning Controls process
drill down to all categories of data
to check for errors, etc
manually adjust budget forecast always err on high side early in
year and make more accurate as
year comes to close (can always
come in under but never over)
Maj Adam Jeppe
Classification Plan
forecast MOS dynamics for each
MOS ( what year do they attain
classification, time to train,
continuation rate )
based on time to achieve
classification, look in tgt force
(GAR) 2 to 4 yrs out for tgt
forecast year of service
distribution for each MOS based
Capt David Barber
End Strength Analysis
(ad hoc on demand)
Enlisted Accession
Planning
Capt David Barber
Classification Plan
6
Capt David Barber
Classification Plan
6
Capt David Barber
Classification Plan
6
Maj Adam Jeppe
Maj Adam Jeppe
Maj Adam Jeppe
Enlisted Accession
Mission
Enlisted Endstrength
Planning
Maj Adam Jeppe
End Strength Analysis
(ad hoc on demand)
Maj Adam Jeppe
Maj Adam Jeppe
Maj Adam Jeppe
Maj Adam Jeppe
Maj Adam Jeppe
Maj Adam Jeppe
End Strength Analysis
(ad hoc on demand)
End Strength Analysis
(ad hoc on demand)
End Strength Analysis
(ad hoc on demand)
End Strength Analysis
(ad hoc on demand)
6
7
7
7
7
6
7
7
7
7
7
7
5
110
on present inventory & number
recruited each year optimize best
feasible approximation to target
force
MOS endstrength must roll up to
aggregate end strength
publish classification plan;
workflow = MPP->MP->CLASS
AUTHORITIES (MMEA11,PENSECOLA, 29 PALMS, SOI
E&W, FT LENWOOD, INTEL
PENTAGON)
Capt David Barber
Classification Plan
6
Capt David Barber
Classification Plan
Enlisted Accession
Planning
Recruiting Targets /
Program Plan
Recruiting Targets /
Program Plan
Recruiting Targets /
Program Plan
6
Recruiting Targets / Program Plan
Capt David Barber
import/edit PEF definitions
Capt David Barber
rollup classification plan into PEFs
determine target for female recuits
by PEF
exclude MOS not open to women;
exclude billets not open to women;
consider effect of imbalances in
resulting from women not
deploying with unit
limit by the number of boat spaces
at Paris Island
Capt David Barber
Recruiting Bonus Plan
import budget from MPP-40
import take rate file (data =
historical averages (need economic
model, but don't have one now)
import classification plan/program
plan
optimize allocation of bonus
budget to help recruiters meet
targets (need take rate file same as
for SRB planning)
publish bonuses; workflow = MPP>MP->M&RA->MCRC
publish program plan inc. tgts &
bonuses (memo 01); workflow =
MPP->MP->M&RA->MCRC
Capt David Barber
Capt David Barber
determine target for
female recuits by PEF
determine target for
female recuits by PEF
Recruiting Targets /
Program Plan
Recruiting Bonus Plan
Capt David Barber
Recruiting Bonus Plan
7
Capt David Barber
Recruiting Bonus Plan
7
Capt David Barber
Recruiting Bonus Plan
7
Capt David Barber
Recruiting Bonus Plan
7
Capt David Barber
Recruiting Targets /
Program Plan
6
Capt David Barber
Capt David Barber
Capt David Barber
5
6
6
6
7
7
6
7
111
(informal collaboration w/MCRC
before official circulation via
workflow)
Enlisted TIP Request - by FY
import approved classification plan
import MOS progression data
forecast attrition and back it back
into plan to get numbers for each
stage of school
publish TIP request; workflow =
mpp->mp->tecom (march tip
conference)
Capt David Barber
Capt David Barber
Capt David Barber
Enlisted Accession
Planning
Enlisted TIP Request
Enlisted TIP Request
5
6
6
Capt David Barber
Enlisted TIP Request
6
Capt David Barber
6
Enlisted Inventory Health Analysis
MOS health reports, provide
connection between accession &
retention plan
Capt Blackmon
Enlisted TIP Request
Enlisted Accession
Planning
Capt Blackmon
Enlisted Inventory
Health Analysis
5
6
References
1. Rosemann, M.: Potential pitfalls of process modeling: part a. Business Process
Management Journal 12(2), 249–254 (2006)
2. A Simple Metric to Measure Semantic Overlap between Models: Application and
Visualization Jean-Paul Van Belle Department of Information Systems, University of
Cape Town
3. C.C. Byrne and S.A. McCracken, An adaptive thesaurus employing semantic distance,
relational inheritance and nominal compound interpretation for linguistic support of
information retrieval, Journal of Information Science 25(2) (1999) 113–131.
4. Business Process Model and Notation (BPMN) 1.1 Business Process Model and Notation
(BPMN) 1.1 Release date: January 2008 ... v1.1: PDF:
http://www.omg.org/spec/BPMN/1.1/PDF: formal/2008-01-17: v1.1
5. Martin Hepp, Frank Leymann , John Domingue, Alexander Wahler and Dieter Fensel.,
2005, “web services for business process management semantic business process
management: a vision towards using semantic”, IEEE International Conference on eBusiness Engineering, 3(05)
6. Smith, Howard; Fingar, Peter: Business Process Management. The Third Wave. MeghanKiffer Press, Tampa, FL, USA 2002.
7. Hepp, Martin et al.: Semantic Business Process Management: A Vision Towards Using
Semantic Web Services for Business Process Management. IEEE International
Conference on e-Business Engineering (ICEBE 2005). Beijing, China, October 18-20,
2005, pp. 535-540.
8. Davenport, T.H., 1993. Process Innovation: Reengineering Work through Information
Technology. Harvard Business School Press, Boston, MA, USA.
113
9. PROCESS, 2003. Modelling and mapping the business process, EPSRC project, home
page at: http://www.ecs.soton.ac.uk/Bkp/process.html.
10. Object Management Group. Business Process Definition Metamodel. Version 1.0.2
(January 12th 2004), http://www.bpmn.org/Documents/BPDM/OMG-BPD-2004-01-12Revision.pdf
11. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., 1991. Object-Oriented
Modelling and Design. Prentice- Hall, Englewood Cliffs, NJ, USA.
12. Wang, S. (1994), ``OO modeling of business processes’’, Information System
Management, spring, pp. 36-43.
13. Aguilar-Saven, R., 2001. Business process modelling: Review and framework. Int. J.
Production Economics 90 (2004) 129–149
14. OMG (2004), UML 2.0 superstructure specification, Technical report.
http://www.omg.org/cgi-bin/doc?ptc/2004-10-02.
15. L. M. Kristensen, L. Wells, and K. Jensen, "Coloured Petri Nets and CPN Tools for
Modelling and Validation of Concurrent Systems," STTT, vol. 9, pp. 213--254, 2007.
16. Dawkins, S., Role Activity Diagrams for Safety Process Definition, 16th International
System Safety Conference, Seattle, WA, System Safety Society, USA, 1998
17. Martinez-Garcia, J.A., Warboys, B.C., From RADs to DESs: a Mapping from Process
Models to Discrete Event Simulation, Proceedings of the Software Process Simulation
Modeling Workshop, ProSim’98, 1998
18. Phalp, K., Henderson, P., Abeysinghe, G., Walters, B., RolEnact – Role Based Enactable
Models of Business Processes, Information and Software Technology, 40(3), pp.123-133,
1998
19. IDEF (2003). Family of Methods web page: http://www.idef.com.
114
20. Curtis, B., Kellner, M. and Over, J. Process Modeling. Communication of the ACM, Vol.
35, No.9, 1992
21. List Beate, Korherr Birgit: An Evaluation of Conceptual Business Process Modelling
Languages, Proceedings of the 2006 ACM Symposium on Applied Computing (SAC’06),
Dijon, France, ACM Press, (2006).
22. Schriber, T. J, Fundamental of Flowcharting, Wiley, New York (1969).
23. ISO 9000 Quality Management. N.p., n.d. Web. 06 Mar. 2013.
24. I. V. Levenshtein. Binary Codes capable of correcting deletions, insertions, and reversals.
Cybernetics and Control Theory, 10(8):707–710, 1966.
25. Alexander Maedche and Steen Staab. Measuring Similarity between Ontologies. In
Proceedings of the European Conference on Knowledge Acquisition and Management (EKAW-2002). Madrid, Spain, October 1-4, pages 251{263, 2002.
26. USMC Total Force Manpower Models Reengineering Software Requirements
Specification Version 3, 31 Mar 2008