University of the Aegean
Business School
Department of Financial and Management
Engineering
Organization of Service Systems using
the Design Structure Matrix
Georgios Kapetanvasileiou
Supervisors: Ioannis Minis and Vassilis Gliatis
Chios, 2011
i
To my parents
and friends
ii
Acknowledgments
As I’m writing the last portion of my thesis I feel indebted to the support and
encouragement of many individuals who, by means of these lines, I would like to
thank. I couldn’t have been more fortunate of choosing Professor Ioannis Minis as my
supervisor. I thank him for giving me the opportunity to enrich my knowledge and
skills but also for making the whole process a fruitful learning experience. I would
also like to thank my advisor Vassilis Gliatis, PhD candidate of the University of the
Aegean for his valuable guidance, patience, and insightful discussions. This work
would have been almost impossible to complete without his great help. Moreover, I
feel grateful for the help and resources made available to me through the DeOPSys
Lab of the Financial and Management Engineering Department of the University of
the Aegean. Last, but not least, I would like to thank my family, my fellow colleagues
at University of the Aegean and friends for their support and friendship all these
years
iii
Summary (In Greek)
SUMMARY (IN GREEK)
Σηελ παξνύζα δηπισκαηηθή εξγαζία παξέρεηαη κηα λέα πξνζέγγηζε γηα ηελ
αμηνιόγεζε νξγαλσηηθώλ δνκώλ ζε ππεξεζίεο ρξεζηκνπνηώληαο ηελ κεζνδνινγία
ηνπ Πίλαθα Δνκήο Σρεδηαζκνύ-ΠΔΣ (Design Structure Matrix-DSM). Επηπιένλ
παξνπζηάδεηαη κηα ζπζηεκαηηθή πξνζέγγηζε γηα ηνλ ζρεδηαζκό θπηηάξσλ εξγαζίαο
(work cells) ζε πεξηβάιινλ ππεξεζηώλ. Η παξνύζα έξεπλα πξαγκαηνπνηήζεθε ζην
πιαίζην εξεπλεηηθήο πξσηνβνπιίαο ηνπ εξγαζηήξηνπ Σπζηεκάησλ Σρεδηαζκνύ
Παξαγσγήο θαη
(Τ
εηηνπξγηώλ ηνπ Τκήκαηνο
Δ), ηνπ Παλεπηζηεκίνπ
εραληθώλ
ηθνλνκίαο θαη Δηνίθεζεο
ηγαίνπ ζηελ νπνία δηεξεπλάηαη ε εθαξκνγή ηεο
θηινζνθίαο,ησλ κεζόδσλ, εξγαιείσλ θαη πξαθηηθώλ ηεο ιηηήο παξαγσγήο (lean
manufacturing) ζε πεξηβάιινλ ππεξεζηώλ.
Η θαηαθόξπθε αλαπηύμε ηνπ ηνκέα ησλ ππεξεζηώλ ηα ηειεπηαία ρξόληα ζηελ
παγθόζκηα νηθνλνκία έρεη ζπληειέζεη ζε κηα ζηξνθή ηεο αθαδεκατθήο θνηλόηεηαο
πξνο ηελ κειέηε θαη αλάιπζε ησλ ιεηηνπξγηώλ ησλ ππεξεζηώλ. Εληνύηνηο, νη
ππεξεζίεο παξνπζηάδνπλ ηδηαίηεξα ραξαθηεξηζηηθά θαη δηέπνληαη από δηαθνξεηηθνύο
θαλόλεο ζρεηηθά ηηο επξέσο δηαδεδνκέλεο πξαθηηθέο πνπ ηζρύνπλ ζηελ βηνκεραλία
(manufacturing). Η ζπκκεηνρή ηνπ πειάηε ζηελ δηαδηθαζία παξαγσγήο, θαζώο θαη ν
κεγάινο βαζκόο εμάξηεζεο ηνπ πξντόληνο από ηνλ εμππεξεηεηή (server), απνηεινύλ
ζεκαληηθέο πεγέο κεηαβιεηόηεηαο ζηα ζπζηήκαηα ππεξεζηώλ. Έηζη, ε επηινγή
θαηάιιειεο νξγαλσηηθήο δνκήο δηαθαίλεηαη επηηαθηηθή γηα ηελ νκαιή ιεηηνπξγία ηνπ
νξγαληζκνύ.
Σην γεληθόηεξν πιαίζην απηήο ηεο δηπισκαηηθήο εξγαζίαο πξαγκαηνπνηήζακε κηα
εθηελή βηβιηνγξαθηθή έξεπλα ζε ζρεηηθά δηεζλή επηζηεκνληθά πεξηνδηθά πξνθεηκέλνπ
λα εληνπίζνπκε ηνπο παξάγνληεο εθείλνπο πνπ επεξεάδνπλ ηελ νξγαλσηηθή δνκή ησλ
ππεξεζηώλ. Σπγθεθξηκέλα εζηηάζακε ηελ έξεπλα καο ζηνλ ηξόπν κε ηνλ νπνίν
πξαγκαηνπνηείηαη ν θαηακεξηζκόο ηεο εξγαζίαο κεηαμύ ησλ εξγαδνκέλσλ, θαη ε
νκαδνπνίεζε ησλ δηαζέζηκσλ εξγαζηώλ ζε ηκήκαηα. Τα απνηειέζκαηα ηεο έξεπλαο
έδεημαλ νηη ε νξγάλσζε ππεξεζηώλ επεξεάδεηαη από πιήζνο παξαγόλησλ θαη δελ
κπνξεί λα αλαιπζεί κνλνδηάζηαηα.
η ζεκαληηθόηεξνη παξάγνληεο επηινγήο
θαηάιιειεο νξγαλσηηθήο δνκήο παξνπζηάδνληαη θαη αλαιύνληαη εθηελώο. Σηελ
ζπλέρεηα, εμεηάζακε ηεο επηθξαηέζηεξεο νξγαλσηηθέο δνκέο ζε ππεξεζίεο, , αιιά θαη
iv
Summary (In Greek)
πβξηδηθέο κνξθέο απηώλ όπσο είλαη ε δνκή ησλ θπηηάξσλ παξαγσγήο
(cells),αλαιύνληαο ηα πιενλεθηήκαηα θαη κεηνλεθηήκαηα έθαζηεο.
Τα θύηηαξα παξαγσγήο (ή εξγαζίαο) έρνπλ ρξεζηκνπνηεζεί επξέσο ζηνλ ηνκέα ηεο
κεηαπνίεζεο παξνπζηάδνληαο ζεκαληηθά πιενλεθηήκαηα από άπνςε απόδνζεο όπσο:
εησκέλε δηάξθεηα ξνήο (flow time), κεησκέλν ρξόλν κεηαθνξάο (move time),
πςειόηεξε εμεηδίθεπζε εξγαδνκέλσλ θαη κείσζε ειαηησκαηηθώλ, βειηησκέλνο
έιεγρνο παξαγσγήο θαη εξγαζίαο, θ.α. Τα θύηηαξα παξαγσγήο βαζίδνληαη ζηελ
νκαδνπνίεζε αλόκνησλ παξαγσγηθώλ πόξσλ ή δηαδηθαζηώλ, πνπ απαηηνύληαη γηα ηελ
παξαγσγή κηα ζπγθεθξηκέλεο νηθνγέλεηαο (family) πξντόλησλ. Ωζηόζν ε εθαξκνγή
ηεο ζπγθεθξηκέλεο νξγάλσζεο ζε πεξηβάιινληα ππεξεζηώλ παξακέλεη πεξηνξηζκέλε
(Swank, 2003; Pagell and Melnyk, 2004; Hameri, 2011). Επηπξνζζέησο, ε αλάιπζε
ησλ δηαζέζηκσλ εθαξκνγώλ ζηελ βηβιηνγξαθία εμαληιείηαη ζην λα θαηαγξάθεη ηα
νθέιε κηα ηέηνηαο αλαδηάηαμεο ρσξίο λα παξνπζηάδεη κηα ζπζηεκαηηθή πξνζέγγηζε
γηα ηελ εθαξκνγή θπηηάξσλ παξαγσγήο ζε ππεξεζίεο (service cells). Σηελ παξνύζα
εξγαζία δηεξεπλάηαη εθηελώο ε δπλαηόηεηα εθαξκνγήο ησλ θπηηάξσλ εξγαζίαο ζε
πεξηβάιινλ παξνρήο ππεξεζηώλ ηξαπεδηθήο. Σηελ έξεπλα απηή θάλακε εθηεηακέλε
ρξήζε ησλ Πηλάθσλ Δνκήο Σρεδηαζκνύ.
Η ΜΕΘΟΔΟΛΟΓΙΑ ΣΩΝ ΠΙΝΑΚΩΝ ΔΟΜΗ΢ ΢ΥΕΔΙΑ΢ΜΟY
Πίλαθαο Δνκήο Σρεδηαζκνύ-ΠΔΣ (Design Structure Matrix-DSM) έρεη απνδεηρζεί
όηη είλαη έλαο απνηειεζκαηηθόο ηξόπνο κνληεινπνίεζεο, νπηηθνπνίεζεο θαη αλάιπζεο
ηνπ ηξόπνπ αιιειεπίδξαζεο κεηαμύ νξγαλσηηθώλ νληνηήησλ. Παξέρεη έλαλ
απνηειεζκαηηθό ηξόπν ραξηνγξάθεζεο ησλ ζρέζεσλ κεηαμύ νληνηήησλ, νκάδσλ ή
δξαζηεξηνηήησλ ηνπ ζπζηήκαηνο ζε αλαιπηηθή κνξθή. Η αλάιπζε απηή κπνξεί λα
επηηξέςεη ηε βειηίσζε ηεο δνκήο πνιύπινθσλ ζπζηεκάησλ.
Σύποι Πινάκων Δομήρ ΢σεδιαζμού
Σηελ βηβιηνγξαθία ζπλαληάκε ηξείο ηύπνπο κεζόδσλ βαζηδόκελεο ζε πίλαθεο:
Design Structure Matrix (DSM)
Χξεζηκνπνηείηαη γηα ηελ κνληεινπνίεζε ζρέζεσλ κεηαμύ νληνηήησλ ελόο κνλαδηθνύ
ηνκέα ηνπ ζπζηήκαηνο (π.ρ. νκάδεο εξγαδνκέλσλ, δξαζηεξηόηεηεο θ.α.).
πνηειεί
v
Summary (In Greek)
έλαλ ηεηξαγσληθό πίλαθα ζηνλ νπνίν ηόζν νη γξακκέο όζν θαη νη ζηήιεο
αληηπξνζσπεύνπλ ζηνηρεία ηνπ ζπζηήκαηνο κε θάζε έλδεημε εθηόο δηαγσλίνπ λα
απνηειεί κηα ζρέζε κεηαμύ ηνπ ελόο ζηνηρείνπ κε ην άιιν. Δηαβάδνληαο θαηά κήθνο
κηαο ζεηξάο, ν πίλαθαο απνθαιύπηεη ζε πνηά άιια ζηνηρεία ην ζηνηρείν ηεο
ζπγθεθξηκέλεο ζεηξάο απνδίδεη δεδνκέλα, ελώ δηαβάδνληαο θάησζελ κηαο ζηήιεο
απνθαιύπηεη από πνηά άιια ζηνηρεία ην ζηνηρείν ηεο ζηήιεο δέρεηαη δεδνκέλα. Γηα
παξάδεηγκα ην Σρήκα Π.1 παξνπζηάδεη ηνλ ηξόπν κεηαηξνπήο ελόο δηθηύνπ ζε DSM.
Σηνλ πίλαθα ζην δεμί ηκήκα ηνπ ζρήκαηνο ην ζηνηρείν Β απνδίδεη δεδνκέλα ζηα
ζηνηρεία
θαη D, ελώ δέρεηαη δεδνκέλα από ηα ζηνηρεία , C θαη D.
Representation
in DSM
΢σήμα Π.1: Αναπαπάζηαζη ζσέζεων ηος ζςζηήμαηορ ζε DSM
Domain Mapping Matrix (DMM)
Χξεζηκνπνηείηαη
δηαθνξεηηθώλ
γηα
ηνκέσλ
ηελ
κνληεινπνίεζε
ηνπ
ζπζηήκαηνο.
ζρέζεσλ
Κάηη
κεηαμύ
ηέηνην
ζηνηρείσλ
δύν
επεθηείλεη
ηελ
απνηειεζκαηηθόηεηα ηνπ DSM. Γηα παξάδεηγκα, ην δίθηπν ζηα αξηζηεξά ηνπ
Σρήκαηνο Π.2 παξνπζηάδεη ηνλ ηξόπν αλάζεζεο θαζεθόλησλ ζε εξγαδνκέλνπο.
πνξνύκε εύθνια λα κνληεινπνηήζνπκε ην ζπγθεθξηκέλν δίθηπν ηνπνζεηώληαο ηνπο
εξγαδνκέλνπο ζηηο γξακκέο ηνπ DMM, θαη ηα θαζήθνληα ζε ζηήιεο. Έηζη
δηαβάδνληαο θαηά κήθνο κηα γξακκήο αλαγλσξίδνπκε πνηόο εξγαδόκελνο εθηειεί
πνηά εξγαζία, ελώ δηαβάδνληαο θάησζελ κίαο ζηήιεο δηαπηζηώλνπκε από πνηόλ
εξγαδόκελν εθηειείηαη ε εξγαζία ζηε ζπγθεθξηκέλε ζηήιε.
vi
Summary (In Greek)
Representation
in DMM
΢σήμα Π.2: Αναπαπάζηαζη ζσέζεων μεηαξύ διθοπεηικών ηομέων ηος ζςζηήμαηορ ζε DMM
Multiple Domain Matrix (MDM)
πίλαθαο MDM απνηειεί πξνέθηαζε ησλ DSM θαη DMM θαη επηηξέπεη ηε
ζπζηεκαηηθή
κνληεινπνίεζε
νινθιεξσκέλσλ
ζπζηεκάησλ,
πνιιαπινύο ηνκείο ηνπ ζπζηήκαηνο ζε κηα ζπγθεληξσηηθή κνξθή.
ζπλδπάδνληαο
MDM είλαη
νπζηαζηηθά έλαο κεγάινο Πίλαθαο Δνκήο Σρεδηαζκνύ ν νπνίνο απνζεθεύεη ζρέζεηο
κεηαμύ ηνπ ίδηνπ ηνκέα ζε DSMs θαη’α κήθνο ηεο δηαγσλίνπ θαη ζρέζεηο κεηαμύ δύν
δηαθνξεηηθώλ ηνκέσλ ζε DMMs εθηόο δηαγσλίνπ (Σρήκα Π.3).
΢σήμα Π.3: Αναπαπάζηαζη ζσέζεων ζςζηήμαηορ ζε MDM
Η ρξεζηηθόηεηα ησλ ΠΔΣ πεγάδεη από ην γεγνλόο νηη oη πίλαθεο κπνξνύλ λα
αλαιπζνύλ πεξαηηέξσ κε ηελ βνήζεηα αιγνξίζκσλ όπσο γηα παξάδεηγκα
νκαδνπνίεζεο δεδνκέλσλ (clustering algorithm).
πηή ε δηαδηθαζία ελδέρεηαη λα
vii
Summary (In Greek)
απνθαιύςεη ζηνηρεία ή ππνζύλνια ηνπ ζπζηήκαηνο ησλ νπνίσλ ε πξνζαξγκνγή
κπνξεί λα βειηηώζεη ηελ απόδνζε ηνπ ζπζηήκαηνο.
ΜΕΘΟΔΟΛΟΓΙΑ ΠΟΤ ΑΚΟΛΟΤΘΗΘΗΚΕ ΚΑΙ ΜΕΛΕΣΗ ΠΕΡΙΠΣΩ΢Η΢
Σε απηή ηελ ελόηεηα πξνζαξκόδνπκε ηελ κεζνδνινγία ησλ Πηλάθσλ Δνκήο
Σρεδηαζκνύ γηα λα αμηνινγήζνπκε δηαθνξεηηθέο νξγαλσηηθέο δνκέο ζε έλα ηππηθό
πεξηβάιινλ ππεξεζηώλ.
Μελέηη Πεπίπηωζηρ (Case study)
Εθαξκόζακε
ηελ
πξνζέγγηζε
καο
ζην
back-office
ελόο
επξσπατθνύ
ρξεκαηνπηζησηηθνύ νξγαληζκνύ. Η εηαηξία πξνζπαζνύζε λα βξεί έλαλ ηξόπν ώζηε λα
αληηκεησπίζεη απνηειεζκαηηθά ηελ απμαλόκελε πνιππινθόηεηα ησλ ππεξεζηώλ ηεο.
Η πνιππινθόηεηα απηή νθεηιόηαλ θαηά θύξην ιόγν ζηηο αιιεπάιιειεο κεηαβηβάζεηο
(handoffs) ηεο εξγαζίαο από ην έλα ηκήκα ζην άιιν δεκηνπξγώληαο ιάζε θαη
αλεπηζύκεηεο επαλαιήςεηο (rework).
Γηα ηελ ζπζηεκαηηθή θαηαγξαθή ησλ ζηνηρείσλ ηνπ ζπζηήκαηνο πξαγκαηνπνηήζακε
πνιύσξεο ζπλεληέπμεηο κε αληηπξνζώπνπο ηεο εηαηξείαο. Επηπιένλ ζε ζπλελλόεζε κε
ηελ δηνίθεζε ηεο εηαηξείαο θαηαιήμακε ζε ηξία ελαιιαθηηθά ζελάξηα νξγαλσηηθώλ
δνκώλ ηα νπνία θαη ζα αμηνινγήζνπκε (Σρήκα Π.4):
i.
ξγάλσζε αλα ιεηηνπξγία (structure organized by Function), δει. νη εξγαζίεο
νκαδνπνηνύληαη ζε ηκήκαηα βάζε ιεηηνπξγηαο,
ii.
ξγάλσζε αλα ππεξεζία (structure organized by Service), δει. νη εξγαζίεο
νκαδνπνηνύληαη ζε ηκήκαηα βάζε ππεξεζίαο, θαη
iii.
ξγάλσζε αλά αγνξά (structure organized by Market), δει. νη εξγαζίεο
νκαδνπνηνύληαη ζε ηκήκαηα βάζε αγνξάο.
viii
Summary (In Greek)
΢σήμα Π.4: ΢ενάπια οπγανωηικών δομών ςπο εξέηαζη (1-3)
Πεπιγπαθή και εκηέλεζη ηηρ μεθοδολογίαρ
ξρηθά απνηππώζακε ην ζύζηεκα κειέηεο ζε έλα Multiple Domain Matrix (MDM).
Τν Σρήκα Π.5 παξνπζηάδεη ηνπο ζεκαληηθόηεξνπο ηνκείο ηνπ ζπζηήκαηνο ππν
εμέηαζε. Επηπιένλ ζην Σρήκα Π.5 θαίλνληαη νη ηύπνη ησλ ζρέζεσλ κεηαμύ ζηνηρείσλ
ελόο ηνκεά αιια θαη ησλ ζρέζεσλ κεηαμύ δηαθνξεηηθώλ ηνκέσλ.
MARKET
SERVICE
JOB
FUNCTION
MARKET
Market has
influence on
Market
Markets request
specific Services
---
---
SERVICE
---
Service depends
on Service
---
---
Job varies
according to the
Market
(1)
Services are
produced through
Jobs
(2)
Job has influence
on Job
(3)
---
---
---
JOB
FUNCTION
Jobs belong to
different
Functions
(4)
Function requires
Function
΢σήμα Π.5: Σομείρ και ηύποι αλληλο-εξάπηηζηρ ζε MDM
ix
Summary (In Greek)
Γηα θάζε έλα από ηα ζθηαζκέλα ηεηξάγσλα ηνπ Σρήκαηνο Π.5 θαηαζθεπάζακε ην
αληίζηνηρν DSM ή DMM.
ε απηό ηνλ ηξόπν κπνξνύκε λα παξάγνπκε δηαθνξεηηθέο
όςεηο ησλ ζρέζεσλ κεηαμύ εξγαζηώλ ηνπ ζπζηήκαηνο (αιιεινεμάξηεζε εξγαζηώλ
ιόγσ ιεηηνπξγηώλ, ππεξεζηώλ θαη αγνξώλ). Σπλδπάδνληαο απηέο ηεο όςεηο
δεκηνπξγήζακε έλαλ ζπγθεληξσηηθό πίλαθα, ν νπνίνο πεξηιακβάλεη ην ζύλνιν ησλ
ζρέζεσλ κεηαμύ εξγαζηώλ ηνπ ζπζηήκαηνο (Σρήκα Π.6).
΢σήμα Π.6: ΢ςγκενηπωηικόρ πίνακαρ ζσέζεων μεηαξύ δοςλειών ηος ζςζηήμαηορ
Ανάλςζη οπγανωηικήρ δομήρ ζςζηήμαηορ
Σηελ ζπλέρεηα πξνρσξήζακε κε ηελ κνληεινπνίεζε ησλ δηαζέζηκσλ ζελαξίσλ.
εηαζέηνληαο ηηο γξακκέο θαη ηηο ζηήιεο ηνπ ζπλνιηθνύ πίλαθα κπνξνύκε λα
δεκηνπξγήζνπκε νκάδεο εξγαζηώλ θαηα κήθνο ηεο δηαγσλίνπ, ηθαλέο λα
αλαπαξαζηήζνπλ ηα δηαθνξεηηθά ηκήκαηα ηνπ νξγαληζκνύ. Γηα παξάδεηγκα, ην
Σρήκα Π.7 αλαπαξηζηά ηελ δνκή ηνπ πξώηνπ ζελαξίνπ. Σε απηό θάζε νκάδα
εξγαζηώλ θαηα κήθνο ηεο δηαγσλίνπ αλαπαξηζηά έλα απν ηα έμη ηκήκαηα ρσξηζκέλα
αλα ιεηηνπξγία.
x
Summary (In Greek)
Επηπιένλ πξαγκαηνπνηήζακε αλάιπζε νκαδνπνίεζεο δεδνκέλσλ (clustering analysis)
ζηνλ ζπγθεληξσηηθό πίλαθα (Σρήκα Π.6) πξνθεηκέλνπ λα αλαγλσξίζνπκε ππνζύλνια
ηνπ ζπζηήκαηνο πνπ είλαη ππνςήθηα γηα θύηηαξα εξγαζηώλ (service cells). Γηα ηελ
αλάιπζε ρξεζηκνπνηήζακε ηνλ αιγόξηζκν ηνπ Thebeau (2001), ηνλ νπνίν
πινπνηήζακε ζε πεξηβάιινλ Matlab.
΢σήμα Π.7: Αναπαπάζηαζη οπγάνωζηρ ανα λειηοςπγία ζε DSM
Κάζε ζελάξην νξγάλσζεο αμηνινγήζεθε βάζε ηεζζάξσλ κεηξηθώλ (structural
assessment metrics):
1. Number of clusters:
αξηζκόο ησλ νκάδσλ πνπ αλαγλσξίζηεθαλ. Όζν
κηθξόηεξνο ν αξηζκόο ησλ νκάδσλ, ηόζν θαιύηεξε είλαη ε νκαδνπνίεζε.
2. Coverage: Πειίθν ησλ αιιεινεπηδξάζεσλ κέζα ζε νκάδεο εξγαζηώλ κε ην
άζξνηζκα ησλ αιιεινεπηδξάζεσλ ηνπ ζπζηήκαηνο. Όζν κεγαιύηεξε απηή ε
ηηκή, ηόζν θαιύηεξε ε νκαδνπνίεζε κεηαμύ δνπιεηώλ.
3. Coordination Cost: Τν θόζηνο νξγάλσζεο ησλ εξγαζηώλ ζύκθσλα κε ηνλ
αιγόξηζκν νκαδνπνίεζεο ηνπ Thebeau (2001). Όζν κηθξόηεξε ε ηηκή ηνπ,
ηόζν θαιύηεξε ε νκαδνπνίεζε κεηαμύ εξγαζηώλ.
xi
Summary (In Greek)
4. Measure of Effectiveness: Τν άζξνηζκα ησλ πειίθσλ κεηαμύ κηάο εξγαζίαο
θαη ησλ πιεζηέζηεξώλ ηεο γεηηόλσλ. Όζν κηθξόηεξε ε ηηκή ηνπ, ηόζν
θαιύηεξε ε νκαδνπνίεζε κεηαμύ δνπιεηώλ.
Τα απνηειέζκαηα παξνπζηάδνληαη ζηνλ Πίλαθα Π.1.
πν ηνλ Πίλαθα απηό γίλεηαη
αληηιεπηό όηη ε νξγάλσζε αλα αγνξά κεηώλεη ζηνλ κεγαιύηεξν βαζκό ηελ
πνιππινθόηεηα ηνπ ζπζηήκαηνο. Επηπιένλ, από ηελ αλάιπζε πξνέθπςε νηη κηα
νξγάλσζε αλα αγνξά απνηειεί νπζηαζηηθά νξγάλσζε θπηηάξσλ εξγαζίαο ζηελ νπνία
θάζε ηκήκα λα κπνξεί λα ιεηηνπξγεί απηόλνκα.
Πίνακαρ Π.1: Πίνακαρ αξιολόγηζηρ οπγανωηικών δομών
Inter-cluster
Structural Views
Market
Function
Service
Modular
Assessment Metrics
# of
Clusters
3
6
3
3
Coverage
Coordination Cost
0,657
0,415
0,559
0,657
424395
466963
599558
424395
Measure of
effectiveness
9465
13653
13216
9465
Ανάλςζη οπγανωηικήρ δομήρ ππώηος κςηηάπος παπαγωγήρ
λαιύζακε, επίζεο, ηελ δνκή νξγάλσζεο ηνπ πξώηνπ αλαγλσξηζκέλνπ θπηηάξνπ
εξγαζίαο πξνθεηκέλνπ λα απνθαζίζνπκε πσο ζα νξγαλσζεί ην θύηηαξν εζσηεξηθό
ηνπ.
Γηα άιιε κηα θνξά ζε ζπλελλόεζε κε ηελ εηαηξεία δεκηνπξγήζακε δύν
ελαιιαθηηθά ζελάξηα νξγάλσζεο (Σρήκα Π.8).
΢σήμα Π.8: ΢ενάπια οπγάνωζηρ ππώηος αναγνωπιζμένος κςηηάπος (3a-3b)
xii
Summary (In Greek)
Γηα ηελ κνληεινπνίεζε ησλ ζελαξίσλ αθνινπζήζακε ηελ ίδηα δηαδηθαζία κε απηή ηεο
πξνεγνύκελεο ελόηεηαο, κόλν πνπ απηή ηελ θνξά ζπκπεξηιάβακε ζηελ αλάιπζε ηα
ηδηαίηεξα ραξαθηεξηζηηθά ηεο θάζε εξγαζίαο (attributes) βαζηδόκελνη ζηνπ
παξάγνληεο νξγάλσζεο ππεξεζηώλ πνπ αλαγλσξίζακε ζηελ βηβιηνγξαθία.
Τα απνηειέζκαηα ηεο αλάιπζεο παξνπζηάδνληαη ζηνλ Πίλαθα Π.2.
Intra-cluster
Structural
Views
Function
Service
Assessment Metrics
# of
Clusters
Coverage
Coordination Cost
Measure of
effectiveness
6
3
0.87
0.426
4752
10057
801.16
389.58
Πίνακαρ Π.1: Πίνακαρ αξιολόγηζηρ ενδο-κςηηαπικών οπγανωηικών δομών
ακβάλνληαο ππόςε ηα απνηειέζκαηα ηνπ Πίλαθα Π.2 θαηαιήμακε όηη
θαηαιιειόηεξν ζελάξην γηα ην πξώην θύηηαξν παξαγσγήο απνηειεί ε νξγάλσζε ησλ
ελδν-θπηηαξηθώλ εξγαζηώλ αλα ιεηηνπξγία (Σρήκα Π.9)
΢σήμα Π.9: Ενδο-κςηηαπική οπγάνωζη ανα λειηοςπγία
xiii
Summary (In Greek)
Σαλ ηειεπηαίν βήκα ηεο κεζόδνπ δηεξεπλήζακε ηηο αλάγθεο ηεο θάζε νκάδαο
εξγαζηώλ εληόο ηνπ θπηηάξνπ σο πξνο ην απαηηνύκελν αλζξώπηλν δπλακηθό θαη
ρξόλν εθπαίδεπζεο. Έηζη κπνξνύκε π.ρ. λα θαηαιήμνπκε ζε κηα πεξαηηέξσ δηάζπαζε
κίαο νκάδαο ηεο νπνίαο νη απαηηήζεηο ζε αλζξώπηλν δπλακηθό θαη εθπαίδεπζε είλαη
κεγάιεο, ελώ αληίζεηα λα νκαδνπνηήζνπκε κηθξόηεξεο νκάδεο ησλ νπνίσλ νη
αληίζηνηρεο απαηηήζεηο είλαη κηθξέο.
΢ςμπεπάζμαηα και Μελλονηική Έπεςνα
Ωο βαζηθά ζπκπεξάζκαηα απηήο ηεο έξεπλαο αλαθέξνληαη ηα εμήο:

Η νκαδνπνίεζε αιιειέλδεησλ δνπιείσλ ζε μερσξηζηά θύηηαξα εξγαζίαο
κπνξεί λα κεηώζεη ζεκαληηθά ηελ πνιππινθόηεηα ηνπ ζπζηήκαηνο.

Η ζύδεπμε εξγαζηώλ (i.e. parallel structure) ε νπνία βαζίδεηαη ζε ηζρπξή
αληαιιαγε πιεξνθνξηώλ κπνξεί λα ππεξθεξάζεη ηηο νηθνλνκίεο θιίκαθαο κηα
νξγάλσζεο ζε ζεηξά (i.e. series structure).
πνηαδήπνηε πεξαηηέξσ έξεπλα ζα έπξεπε λα επηθεληξσζεί ζηελ επηθύξσζε ησλ
εμαρζέλησλ απνηειεζκαησλ κε ηελ βνήζεηα πξνζνκνίσζεο. Επηπιένλ, κειινληηθή
έξεπλα ζα κπνξνύζε λα πξαγκαηνπνηεζεί ζηελ αλάιπζε θαη αλάπηπμε κνληέισλ ηα
νπνία ιακβάλνπλ ππόςε ελαιιάθηηθά δίθηπα δηαλνκήο ππεξεζηώλ ή ηεο δηαδξνκήο
ηνπ πειάηε.
xiv
Contents
1. Thesis Motivation and Objectives .......................................................................... 1
Thesis Outline ....................................................................................................... 3
2. Introduction to Service Operations......................................................................... 4
2.1. Service Characteristics- Differences with Manufacturing ................................ 4
2.2. Sources of Variability in Services ................................................................... 6
2.2.1. External Variability .................................................................................. 6
2.2.2. Internal Variability ................................................................................... 8
3. Organizational Structure of Service Systems ......................................................... 9
3.1. Aspects of Organizational Structure in Service Systems .................................. 9
3.2. Factors Influencing Organization Design in Services .................................... 10
3.2.1. Degree of Customer Contact .................................................................. 10
3.2.2. Service Breadth and Bundling ................................................................ 11
3.2.3. Diagnosis Complexity ............................................................................ 12
3.2.4. Job Complexity ...................................................................................... 12
3.3. Typical Service Structures ............................................................................ 14
3.3.1. Series Structure ...................................................................................... 14
3.3.2. Parallel Structure.................................................................................... 15
3.3.3. Specialization Structure.......................................................................... 16
3.3.4. Bottom-Up and Top-Down Structures .................................................... 17
3.4. Hybrid Service Structures ............................................................................. 21
3.4.1. The Case Manager Approach ................................................................. 21
3.4.2. Service Cells .......................................................................................... 22
4. The Design Structure Matrix................................................................................ 24
4.1. Literature Review ......................................................................................... 24
4.2. Types of Matrix-based Methods .................................................................... 25
4.2.1. Design Structure Matrix (DSM) ............................................................. 25
4.2.2. Domain Mapping Matrix (DMM) ........................................................... 27
4.2.3. Multiple Domain Matrix (MDM) ........................................................... 28
4.3. System Structure Analysis ............................................................................ 31
4.3.1. Clustering .............................................................................................. 31
4.3.2. Partitioning, banding and tearing ............................................................ 33
4.4. Limitations of the DSM ................................................................................ 33
xv
5. Methodology followed and Case Study................................................................ 36
5.1. Methodology Overview ................................................................................ 36
5.2. Case Study Environment ............................................................................... 36
5.3. Description, Application, and Adaptation of Methodology in the Financial
Services Case ...................................................................................................... 43
5.3.1. System Definition .................................................................................. 43
5.3.2. Information Acquisition ......................................................................... 45
5.3.3. Deduction of Indirect Dependencies ....................................................... 51
5.3.4. Structure Analysis .................................................................................. 55
5.3.5. Intra-cluster Structure Analysis .............................................................. 62
6. Conclusions and Further Work ............................................................................ 69
6.1. About the Research Method .......................................................................... 69
6.2. Research Results ........................................................................................... 69
6.3. Future Research ............................................................................................ 70
References ............................................................................................................... 71
Appendix A : The Clustering Algorithm .................................................................. 77
Appendix B : Partitioning ........................................................................................ 80
Appendix C : Deduction of Indirect Dependencies .................................................. 82
Appendix D : Case study Information Acquisition Data........................................... 84
Appendix E Options for Converting a Process Model into DSM .............................. 90
Appendix F : Structural Metrics to assess modularity .............................................. 94
xvi
List of Figures
Figure 3.1: Series Structure ..................................................................................... 14
Figure 3.2: Parallel Structure ................................................................................... 15
Figure 3.3: Specialization Structure ......................................................................... 16
Figure 3.4: Bottom-Up Structure ............................................................................. 18
Figure 3.5: Top-Down Structure .............................................................................. 18
Figure 3.6: Classification of service system structures ............................................. 19
Figure 4.1: Representation of system’s dependencies in DSM ................................. 26
Figure 4.2: Representation of inter-domain dependencies in DMM .......................... 28
Figure 4.3: System network representation in a Multiple Domain Matrix ................. 29
Figure 4.4: Intra-domain dependencies representation in DSMs ............................... 30
Figure 4.5: Inter-domain dependencies representation in DMMs ............................. 30
Figure 4.6: Component-based matrix of an automobile climate control system ........ 32
Figure 4.7: Clustered matrix of the component-based DSM ..................................... 33
Figure 4.8: Structural characteristics depiction by realignment of the DSM ............. 34
Figure 4.9: Indirect dependency depiction between two persons due to component
interrelation ..................................................................................................... 35
Figure 5.1: Swim-lane of Service 1 jobs with network probabilities ......................... 38
Figure 5.2: Swim-lane of Service 2 jobs with network probabilities ......................... 39
Figure 5.3: Swim-lane of Service 3 jobs with network probabilities ......................... 40
Figure 5.4: Service organization structure scenarios 1-3 to be assessed .................... 42
Figure 5.5: Domains and types of dependencies in the MDM .................................. 44
Figure 5.6: Process-Matrix: Process flow based on swim-lanes................................ 47
Figure 5.7: Part of Process-Matrix (Figure 5.6) ........................................................ 48
Figure 5.8: DMMs connecting Jobs with Services, Markets and Functions .............. 50
Figure 5.9: “Job A and Job B are linked to each other when they both are part of the
same Market, Service or contribute to the same Function” ............................... 51
Figure 5.10: Computed Job dependencies via Markets ............................................. 52
Figure 5.11: Computed Job dependencies via Services ............................................ 53
Figure 5.12: Computed Job dependencies via Functions .......................................... 54
Figure 5.13: Modeling the Aggregated view ............................................................ 56
Figure 5.14: Weighted matrix with varying interactions. Scenario 1: Organization by
Function .......................................................................................................... 57
xvii
Figure 5.15: Weighted matrix with varying dependencies. Scenario 2: Organization by
Service............................................................................................................. 58
Figure 5.16: Weighted matrix with varying interactions. Scenario 3: Organization by
Market ( also Modular scenario) ...................................................................... 59
Figure 5.17: Best case scenario for inter-cluster analysis ......................................... 62
Figure 5.18: Scenarios 3a-3c for the assessment of platform's modular sub-structures
........................................................................................................................ 63
Figure 5.19: Computed job dependencies via attributes for the 1st identified cell ..... 64
Figure 5.20: Weighted matrix with varying interaction types for scenario 3 ............. 65
Figure 5.21: Weighted matrix with varying interaction types for scenario 3b ........... 66
Figure 5.22: Best case scenario for intra-cluster structure ........................................ 67
Figure B.1: Activity-based DSM of an automobile design process ........................... 80
Figure B.2: Partitioned matrix of activity-based DSM ............................................. 81
Figure C.3: Possible cases 1 to 3 for computing an aggregated DSM within a MDM 82
Figure C.4: Possible cases 4 to 6 for computing an aggregated DSM within a MDM 83
xviii
List of Tables
Table 3.1: Organizational structure and related areas ............................................... 10
Table 3.2: Factors and values for deciding on the appropriate service delivery
structure........................................................................................................... 21
Table 5.1: Procedure of Structural Complexity Management ................................... 36
Table 5.2: System elements under consideration ...................................................... 41
Table 5.3: Inter-cluster assessment table .................................................................. 61
Table 5.4: Intra-cluster assessment table .................................................................. 66
Table 5.5: Analysis of service sub-cells within first Market department ................... 68
Table D.1: Worksheet .............................................................................................. 84
Table D.2: Average Demand for Service 1-3 across three Markets .......................... 89
xix
Abstract
This diploma thesis provides a methodology for assessing organizational structures in
service operations using the Design Structure Matrix. We also introduce a systematic
approach for the design of cells in services. An overview of service characteristics and
differences with manufacturing is presented, highlighting sources of variability in
service operations. Subsequently, we investigate the factors that play a decisive role in
the selection of service organizational structures, and present the different structure
types. Lastly, we adapt the Design Structure Matrix methodology in order to assess
and design organizational structures in typical service settings. The approach
developed reduces system’s complexity considerably and facilitates the design of
service cells.
xx
Ch a pt er 1: Thesis Motivation and Objectives
1. Thesis Motivation and Objectives
Over the past 40 years services have seen considerable growth in the worldwide
economy, enabling the service sector to surpass traditional industries such as
manufacturing. The service sector includes a broad range of business activities, such
as banking, insurance, transportation, healthcare, professional services, and so forth.
This significant growth has led service firms to increasingly adopt more sophisticated
and complex system structures largely in response to customers’ requests for higher
levels of customization and responsiveness. In today’s competitive environment,
service businesses more than ever face the need for more efficient management and
coordination, which will enable them to deal with the inherent variability and
complexity of their operations.
Nonetheless, research in the area of service operations has been limited. Most of
existing principles concerning the organizational design of service systems are based
upon the insights and methods developed for the manufacturing sector. However, the
nature of service operations is unique. Service operations, as opposed to
manufacturing, are characterized by the variability introduced by customer’s
participation in the delivery process, as well as the dependency of the service to the
server. Thus, the choice of an appropriate structure that can cope with external and
internal variability is of critical concern for the performance of the organization.
Lately, a business trend towards “lean” thinking is being leveraged. Many
manufacturing companies have adopted the principles of lean manufacturing
significantly improving their productivity. At the heart of these practices lie the
concepts of group technology and cellular manufacturing. A cellular design is
accompanied by gains in both performance and flexibility. The easily reconfigured
modular components enable a firm to respond more readily to changing markets and
demands. Although manufacturing literature is filled with examples of cellular
applications, the implementation of cells in service environments is limited.
Additionally, the few examples of group technology in services are restricted to
presenting the results of such an implementation, but rarely propose a systematic
approach for forming service cells.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 1
Ch a pt er 1: Thesis Motivation and Objectives
A major program in the Design Operation and Production Systems Laboratory
(DeOPSys Lab) of the University of the Aegean is investigating Lean Services, i.e.
the application of lean principles in service operations. Within this concept, the scope
of our study is to propose a systematic approach for the formation of cells in a service
environment. In doing so, we employ the Design Structure Matrix (DSM). DSM is a
matrix-based tool for modeling and analyzing complex systems. DSM’s power stems
from its ability to provide an efficient way of mapping and analyzing system
relationships among components, teams, or activities in a compact, visual and
analytical format. To the best of our knowledge this is the first time DSM’s
methodology is applied to a service setting.
The present thesis includes an extensive literature search in the field of service
operations and organizational design. Based on existing results in the service
literature, we identify the factors influencing organizational structures in service
systems. Subsequently, we investigate different prevailing organizational structures in
services, such as the Production Line and the Case Manager approach proposed by
Apte et al (1999), parallel, specialized, bottom up and top down structures as
identified by Buzacott (2000), and Service Cells as defined by Pagell & Melnyk
(2004). In order to assess and design organizational structures in typical service
settings, we adapt the Design Structure Matrix methodology. This approach reduces
system’s complexity considerably, and facilitates the design of service cells. We
apply the proposed method to a complex case study.
Research Gaps and Contribution of the Thesis
Several authors have attempted to address issues such as how should work be
organized in service operations, and which factors influence a firm’s choice of
organizational design. Nevertheless, the majority of them are focused around service
structure taxonomies leading to somehow vague choices.
Another issue that concerns us is the application of manufacturing cells in service
settings. Although manufacturing literature is filled with modular design applications,
service cells implementations have been limited (Swank, 2003; Pagell and Melnyk,
2004; Hameri, 2011). Moreover, although the existing studies document the
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 2
Ch a pt er 1: Thesis Motivation and Objectives
advantages and benefits associated with a modular structure implementation, they all
fail to present a systematic approach for designing cells in service environments.
This thesis presents a novel methodology for assessing organizational structures in
service operations. Moreover, we introduce a systematic approach for the design of
cells in services. Overall, the contributions of this thesis are summarized to:
 New methodology for assessing service structures using the Design Structure
Matrix
 Systematic approach for designing manufacturing cells in service settings
 First Design Structure Matrix methodology application in service settings
Thesis Outline
The remainder of the thesis is structured as follows: Chapter 2 presents the unique
characteristics of services and their differences with manufacturing. In Chapter 3 we
discuss significant aspects of organizational structure in service systems, analyze the
factors that play a decisive role in the organizational design, and present the available
service structures in the related literature. In Chapter 4 we present the Design
Structure Matrix (DSM) and we explain its applicability and limitations. In Chapter 5
we introduce a systematic approach for assessing organizational structures in service
systems and design service cells. Finally, Chapter 6 captures the conclusions of this
work, and directions for further research.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 3
Ch a pt er 2: Introduction to Service Operations
2. Introduction to Service Operations
Over the last 40 years there has been a steady shift of the worldwide economy towards
services. 73,2% of the European Union and 63,6% of the global gross domestic
product (GDP) is attributed to the service sector, while the industrial sector (i.e.
manufacturing), for the same period, constituted 25% and 30,7% of GDP, respectively
(International Monetary Fund, 2011). From the figures above, we conclude that we
are in a “post-manufacturing” era, with services representing the prime mover of the
worldwide economy. To overview key aspects in the field of service operations, we
present in this Chapter the nature and unique characteristics of services, as well as
their similarities and differences to manufacturing.
2.1. Service Characteristics- Differences with Manufacturing
Although many of the well-known principles of manufacturing operations are also
applicable to services, others fail to apply mainly due to the non-standardized nature
of service operations. As a result, professional work and complex service systems
tend to exhibit unconventional behavior with respect to production operations (Hopp
et al., 2009).
The characteristics of services that are distinct from manufacturing fall into three
areas: a) Object of Transformation, i.e. the customer, the information and the material,
b) Service Production, i.e. interaction with the customer and the production process
and finally c) Service Output, i.e. the outcome of the transformation.
Object of Transformation
The major object of transformation in services is the customer. However, in certain
industries (e.g. banking and insurance), information plays a significant role; hence the
term information intensive services (Apte et al., 1999). Service operations involve to a
lesser degree the transformation of material (e.g. restaurants, repair etc.).
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 4
Ch a pt er 2: Introduction to Service Operations
Service Production
Service production refers to the delivery process of the service. Service delivery
exhibits some unique characteristics mainly due to server’s interaction with the
customer and customer’s participation to the delivery process. Relevant issues
include:
Server dependence refers to the dependency on the server for executing the service.
Thus, service delivery depends to a large extend on the cognitive skills and attitudes
of the service worker (Apte et al., 1999).
Customer Participation: In most service environments, such as banking or health
care, customers are active participants of the delivery process. As a result they
introduce a great deal of variability in the system that cannot be easily accommodated.
Simultaneity: Services are produced and consumed simultaneously; thus, services
cannot be inventoried and variability can be buffered only by capacity and time (Hopp
and Spearman, 2000). Moreover, the simultaneity of services may create quality
issues, since a service, compared to a product, cannot be inspected prior delivery.
Perishability: Services, as long as they are not consumed during the time they are
produced, are lost. For example, an empty seat in a cinema or an empty bed in a
healthcare clinic is translated as capacity lost for the service business.
Service Output
As mentioned above services involve the handling of information rather of material
during the transformation process. Moreover, customer’s involvement to the delivery
process is a separate contingency that acts unexpectedly. As a result, the yield of the
service production process (i.e. service output) differentiates from the production of
goods.
Intangibility: Services are intangible. Compared to the tangible nature of goods, what
is produced in services usually does not have material existence. Thus, it is often
difficult for a customer to evaluate the quality of the service whereas someone who
purchases a tangible product can summon up his touch, smell or taste in order to
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 5
Ch a pt er 2: Introduction to Service Operations
assess the quality of the acquired product. (Nesheim, 1990; Lievens and Moenaert,
2001).
Heterogeneity: Each service is unique. Individual customer’s requests, preferences,
capabilities and effort differ significantly. Moreover the location, time, server, or
circumstances under which the service is produced are unlikely to be imitated even if
the same customer requests the same service. Thus services, as opposed to
manufacturing, cannot be easily standardized.
The above characteristics have been debated since a) some of these are also applicable
to manufacturing, and b) they are not universal and change with technological
progress (e.g. the internet and other self-service technologies). For instance, some
services can be produced without the customer’s presence (e.g. entertainment, webbased services). Additionally, it is common for most services to involve some tangible
parts (e.g. fast-food, banking). However, as one of the top service scholars states
(Edvardsson et al., 2005): “These generic characteristics are helpful in
understanding the nature of services if they are properly qualified. They are not as
universal as originally posited and, because they are not, we don’t need to discard
them, but we need to understand the conditions under which they do and do not
apply”.
2.2. Sources of Variability in Services
According to Buzacott (2000) and Harvey et. al. (1997), there are two types of
variability: internal and external. Internal variability rises from the aspects of the
product and process, the workforce and organizational structure. External variability
stems from market characteristics, and customer requirements such as the timing or
mix of the demand. Successful accommodation of external variability usually creates
value for the customer.
2.2.1. External Variability
According to Frei (2006), the customer’s introduced variability stems from the
following sources
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 6
Ch a pt er 2: Introduction to Service Operations
Arrival Variability
Customers’ demand patterns vary significantly. Customers do not all request service
at the same time, and they are not amenable to making concessions regarding the
range of times they are served. Thus, the challenge for service businesses is matching
capacity with demand. Many firms have long ago recognized the need to address
arrival fluctuations using alternative delivery channels (ATMs, 24/7 call centers, or
yield management in the hospitality and airline industries.)
Request Variability
In many service businesses, customer needs are not known in advance, creating
excessive variability and uncertainty. A customer ordering diner could theoretically
choose from an very high number of potential dish variations. A common
countermeasure for dealing with variability in customer requests is the introduction of
menus that allow customers to choose the offering that is closer to their individual
needs.
Capability Variability
Capability refers to the customer’s ability to perform certain tasks during the delivery
of a process. Each customer’s capability clearly differs in terms of physical abilities,
skill, knowledge or resources. For example, some customers may not have the
knowledge or the background to operate an ATM or a web site.
Effort variability
The time and energy each customer is willing to invest in a task depends on its
character, past experience and priorities. A student’s performance in college is not
correlated directly to her/his professor’s expertise. The student who puts more effort
and study more will eventually do better.
a. Subjective Preference Variability
Due to service’s intangible nature, the work outcome does not have well-defined
metrics, as is often the case in manufacturing. Performance and quality measures are
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 7
Ch a pt er 2: Introduction to Service Operations
based on personal preferences, expectations and judgments. As a result, individual
customers may assess differently the quality of a service.
2.2.2. Internal Variability
Having decided on how much external variability the system must cope with, service
firms should structure their processes and organization accordingly. For example, if a
company decides to develop a process that targets multiple market segments, it should
also find an effective way of dispatching the right customer to the right process.
In addition, variability caused by internal to the company factors (such as failures,
inflexible processes and organizational structures) should be continuously improved,
since this does not create any value for the customer.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 8
Ch a pt er 3: Organizational Structure of Service Systems
3. Organizational Structure of Service Systems
3.1. Aspects of Organizational Structure in Service Systems
Organizational structure is a broad subject related to all business areas, and
researched extensively. In the manufacturing and service operations literature, for
example, the structure of a system relates to the work organization, job design and the
layout of facilities. Job design and work organization refer to decisions for allocating
jobs to people and machines (i.e. division of labor), grouping of individual jobs (i.e.
departmentalization) and methods for performing them. It is also concerned with the
environmental conditions of the workplace and ergonomics. Facility layout is
concerned with the physical grouping and location of the resources within the
production facility. Furthermore, in service operations, due to the customer’s
presence, layout decisions extent to areas such as ambient conditions of the facility,
service path for the customer, and effective dispatching of customer to the right
process through signs, symbols and artifacts (Chase & Jacobs, 2006).
From the Human Resources perspective, the organizational structure involves
additional topics such as the distribution of authority among roles (i.e. Distribution of
power) and the appropriate size of the group reporting to each supervisor (i.e. Span of
control).
In Table 3.1 we present a summary of the different areas involved in developing the
service organizational structure. The focus of the current work is on the first two areas
(division of labor, departmentalization). Specifically, our work aims to create a
systematic approach for allocating service tasks to employees to form departments.
Our research starts with the identification of factors and criteria that play a decisive
role in designing services. The factors presented in the next section are part of an
extensive literature search in service organizational literature.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 9
Ch a pt er 3: Organizational Structure of Service Systems
Table 3.1: Organizational structure and related areas
#
Area
Definition
1.
Division of Labor (Manufacturing,
Service Operations &
Organizational Behavior)
2.
Departmentalization
(Manufacturing, Service
Operations & Organizational
Behavior)
3.
Distribution of Power
(Organizational Behavior)
Distribution of authority among roles
(J. L. Gibson et al., 1997; Jay R. Galbraith
1995)
4.
Span of control (Manufacturing,
Service Operations &
Organizational Behavior)
The number of people constituting the
departments at each level of structure (i.e.
the appropriate size of the group reporting to
each supervisor) (J. L. Gibson et al., 1997;
Jay R. Galbraith 1995)
5.
Facility Layout (Manufacturing &
Service Operations)
The physical location of the resources used
(Chase et al., 2006)
6.
Ambient Conditions
(Service Operations)
Noise level, music, lighting, temperature etc.
(Chase et al., 2006)
7.
Spatial Layout and Functionality
(Service Operations)
Planning the circulation path of the customer
and grouping the merchandise (Chase et al.,
2006)
8.
Signs, Symbols, Artifacts (Service
Operations)
Planning the effective dispatching of the
customer (Chase et al., 2006)
9.
Ergonomics
(Manufacturing & Service
Operations)
The physical arrangement of the work space
together with the tools used to perform a job
(Chase et al., 2006)
10. Work Methods
(Manufacturing & Service
Operations)
How the job is done, when and how long the
The allocation of tasks to people and
machines
(J. L. Gibson et al., 1997; Jay R. Galbraith
1995)
The grouping of individual jobs into
departments (J. L. Gibson et al., 1997; Jay
R. Galbraith 1995)
process takes (Chase et al., 2006)
3.2. Factors Influencing Organization Design in Services
3.2.1. Degree of Customer Contact
The concept of the customer participation in service delivery influenced significantly
the service literature and is a significant factor for practitioners in organizing service
work. In their seminal paper Chase and Tansik (1983), distinguished service activities
into those with high and those with low customer contact. According to this approach,
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 10
Ch a pt er 3: Organizational Structure of Service Systems
high customer contact activities are more complex and more difficult to control due to
the customers’ imposed variability. On the other hand, low-contact activities are less
variable and, hence, easier to manage. Thus, the authors advocated that customer
contact work should be decoupled from non-contact work, and managed separately
(front versus back offices). From a layout point of view, front office activities should
be located close to the customer, whereas back-office activities can be located near to
the required resources. Moreover, high contact personnel need interpersonal skills on
top of technical skills.
Although the customer contact model presented an early systematic approach for
classifying service systems, it was later extended with new insights in organizational
design literature. Metters and Vargas (2000) added that decoupling high contact
activities from low contact activities and assigning them to individual groups of
people is only one way of structuring front office and back office. Both Metters and
Vargas (2000) and Zomerdijk and de Vries (2007) argue that under different strategic
decisions diverse front-office back-office configurations can evolve. For example
high and low contact activities can be kept coupled to facilitate workflow
coordination, avoid handovers of work and prevent idle time of employees (see for
example the “Kiosk” strategy presented by Metters and Vargas, 2000). However, even
if not applicable in all situations, the concept of high-low customer contact activities
is still useful for organizing service work.
3.2.2. Service Breadth and Bundling
Customers increasingly demand a wider breadth of options and more customized
services. As a result, when increasing the range and variety of services provided, the
service structure should be adjusted accordingly to accommodate customer needs.
However, the decision on how much variety to offer is a strategic one. For instance if
the firm chooses to follow a specialization strategy, it can target specific market
segments with highly focused and specific services. Overall, a system structured with
wide service coverage is expected to have a different structure than a system that
chooses to exclude some market segments from its operations.
One additional important consideration is that service offerings should be bundled
from the customer point of view; in today’s fast-changing business environment,
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 11
Ch a pt er 3: Organizational Structure of Service Systems
customers desire to be served quickly and efficiently. There is little tolerance for the
server’s inability to handle their diverse claims, and customers may get frustrated
when they have to deal with multiple servers in order to fulfill their needs. As Harvey
et. al. (1997) highlight, “customers seek to get a maximum of results from a minimum
number of servers”. As a result the more flexible a server is in dealing with multiple
demands, the more value for the customer. Under this perspective, the organization
should target offering as many related services as possible (i.e. one-stop-shop) by a
single worker.
3.2.3. Diagnosis Complexity
As the range of services increases, so does the uncertainty in processing the
requirements of each customer. Not all necessary tasks may be evident before the
customer arrives, since some of them will only become apparent as the service
process proceeds. Buzacott (2000) states that “it is not known what customers will
want from the service provider until they are actually being served”. A customer
walking in a computer repair store can’t fully describe the source of his computer’s
malfunction, and thus isn’t capable of determining the service type that is appropriate
for his case. In situations like the one described above, it falls to the server’s judgment
to relate customer’s requirements to an appropriate set of tasks. Consequently, the
service requires diagnosis, which according to Buzacott (2000), may range from
instantaneous (i.e. requiring zero time) to more complex. As the complexity of the
diagnostic tasks increases, so do the technical requirements of the service personnel
and the level of discretion they have to exercise. Thus, service delivery structure must
also compensate for the uncertainty in customers’ processing requirements.
3.2.4. Job Complexity
Job complexity refers to the relevant complexity of the procedures, steps, required
knowledge or perceived risk of individual tasks during the delivery process. Job
complexity is an important aspect of production and significantly affects how work is
organized. The level of job complexity is determined by various factors:
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 12
Ch a pt er 3: Organizational Structure of Service Systems
Discretion
Discretion is defined as the extent to which an employee needs to exercise his
personal judgment during the delivery process (Hopp et. al. 2007, 2009). A physician
operating in a hospital, for instance, has to exercise sufficient discretion in order to
relate patient’s symptoms with adequate treatment. Additionally, discretion relates to
the degree of customization of the service process to suit the needs of individual
customers. Customized services are characterized by a more personalized process
with multiple configurable parameters and greater skills for the employees.
On the other hand, standardized services have limited configurable parameters,
involve minimum variability and can be easily rationalized and automated ensuring
consistent quality in every output. Furthermore, routine tasks usually require lower
level of skills, thus, enabling the employment of inexpensive workers with little crosstraining (Apte et. al., 1999; Ponsignon et. al., 2011).
Job’s Technical & Interpersonal Skills and Learning Curve
Learning and skills play a decisive role in the designing of structures of white-collar
systems (Buzacott, 1999; Pinker and Shumsky, 2000; Hopp et al., 2009). According
to Buzacott (2000), as the cognitive demands and range of individual tasks increases,
so does the overall complexity of the system. Furthermore, Pinker and Shumsky
(2000) argue that, in contrast to the classic learning curves in manufacturing, due to
the vast variability in customers’ requirements, a service worker does not gain the
same experience from each customer served. Thus, regarding the choice of
appropriate structure, the authors conclude that in large systems with slow learning
rate an all-flexible servers structure is preferable. On the contrary, when the learning
is fast and the system is large an all specialized structure will be recommended.
People related risks
Another consideration in designing the organizational structure is the risk of loss
resulting from inadequate or failed practices from people. For instance, in financial
services a sales agent proximity to the customer is seen from many firms as a risky
option as they might act at the firm’s expense (Davenport & Nohria, 1994). For
example, Zomerdijk and de Vries (2007) showed that for the process of providing
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 13
Ch a pt er 3: Organizational Structure of Service Systems
mortgages, most banks decided to separate the actual transfer of funds, assigning them
to a centralized Mortgage Support Centre, in order to allow counterchecks and prevent
conflicts of interest between the bank and its sales advisors. As a result, although for
some processes the coupling of activities can be considered as an appealing
consideration, people related risks might make it prohibitive.
3.3. Typical Service Structures
Based on the factors and criteria identified in the service organizational design
literature, the following five structures are the most typical ones:
3.3.1. Series Structure
In a series structure (see Fig. 3.1) each worker is given a small number of tasks, with
work moving linearly following the progressive steps by which the service is created.
Thus, multiple workers are needed to produce the service required by a customer. The
series structure favors standardized services with well-defined tasks and
nondiscretionary task completion (NDTC) characteristics (Apte et al., 1999; Buzacott,
2000). Buzacott (2000) concludes that a series structure is preferred when there is
very little variability in time to perform the required tasks and when also the
variability between arrivals is small.
Figure 3.1: Series Structure
Source: “Service System Structure”, (Buzacott, 2000)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 14
Ch a pt er 3: Organizational Structure of Service Systems
A typical example of the series structure is the Production Line approach introduced
by the McDonalds restaurants (Levitt, 1972). The Production Line approach
represents one of the early attempts to apply manufacturing concepts to the service
sector (Apte et. al. 1999). Nevertheless, the limitations of this structure need to be
taken into consideration, since this approach favors standardized outputs. In more
complex environments it can create rework due to handoffs of work but also lack of
accountability amongst employees towards the customer (Apte et. al., 1999).
3.3.2. Parallel Structure
In a parallel structure (see Fig. 3.2) a worker is responsible of performing all tasks
required by a customer; i.e. the entire service is provided by a single worker. Thus,
different customers would have to deal with different servers (Buzacott, 2000). A
parallel structure becomes attractive in situations where due to higher arrival or
process variability, traditional division of labor fails (Apte et. al. 1999; Buzacott,
2000). Both Apte et al., (1999) and Buzacott, (2000) resolve that in systems with high
arrival or process variability, a parallel structure would suffer less average queue
lengths and cycle time.
Figure 3.2: Parallel Structure
Source: “Service System Structure”, (Buzacott, 2000)
Nonetheless, as the number of services increases, so does the complexity of the work.
Parallel servers dealing with multiple service offerings are prone to making mistakes,
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 15
Ch a pt er 3: Organizational Structure of Service Systems
since each type of service requires different process paths, and hence, tasks are less
routine (Apte et. al., 1999). Additionally, workers have to exercise significant
discretion in order to relate customer’s requirements to the appropriate set of tasks
(Buzacott, 2000). As a result, business firms implementing a parallel structure need to
invest in workers’ cross-training, as well as to appropriate information systems, thus,
increasing the overall cost of operations (Apte et. al., 1999).
3.3.3. Specialization Structure
In this structure, a worker specializes on set of tasks required for a specific customer
type so there would be different workers for different customer types (Buzacott,
2000). This structure (see Fig. 3.3) is applicable when the processing requirements of
different customer types differ significantly, and, at the same time, customers are
capable of distinguishing the type of service that fits their needs best and choose the
appropriate server.
Figure 3.3: Specialization Structure
Source: “Service System Structure”, (Buzacott, 2000)
Pinker and Smunsky (2000), invoking an experience-based service quality model,
indicated that although flexible workers (i.e. Parallel structure) provide more
throughput with fewer workers, the quality of the system’s output may deflate as the
server may not accumulate sufficient experience, and thus, is less efficient. Moreover,
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 16
Ch a pt er 3: Organizational Structure of Service Systems
they suggest that for large systems (i.e. systems with high arrival load) and with high
learning rates, an all specialized server system will always be beneficial.
3.3.4. Bottom-Up and Top-Down Structures
As soon as customers have difficulty in determining the type of service that suits their
needs, and the service requirements of different customer types are significantly
different, it is crucial to incorporate a diagnostic element in the system’s structure.
According to Buzacott (2000), one way of dealing with this situation is separating
diagnosis from the tasks following the diagnosis; thus a worker performs either
diagnostic tasks or tasks associated with the service pointed to by the results of the
particular diagnosis. Thus, the design of the service system involves two aspects that
need to be considered. First is the structure of the diagnosis, and second is the
structure of the system that performs tasks subsequent to the diagnosis. Regarding the
second aspect, in this case due the complexity of the tasks involved, specialization is
generally preferred. Any other choice would either be more costly or less capable of
dealing with the associated variability.
The diagnostic process can be structured in two major ways: a) the diagnostic tasks
are allocated to a number of workers, with the complexity of the process increasing
with successive steps (Bottom-up), or b) one server performs all the diagnostic tasks,
with complexity decreasing with each step (Top-down). Figure 3.4 illustrates the first
case. By the time the service request arrives the first worker takes on the task of
identifying its requirements. Based on the results of his initial diagnosis he passes
work to the next worker. Note that work for the second worker has become simpler.
The second worker based on the outcomes of his tests will either perform some of the
service’s tasks or will divert work to a third worker for further tests and service.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 17
Ch a pt er 3: Organizational Structure of Service Systems
Figure 3.4: Bottom-Up Structure
Source: “Service System Structure”, (Buzacott, 2000)
For an example of a bottom up structure, consider the case of junior physicians in a
hospital. Normally, they perform series of tests to a patient; in case the diagnosis is
complex or they cannot reach a conclusion, they will assign the patient to a more
senior physician. On the other hand a top down structure may be illustrated by
considering a law office, in which customers would first contact a senior lawyer who
would identify the appropriate action and then assign it to a junior or specialized
lawyer..
Figure 3.5: Top-Down Structure
Source: “Service System Structure”, (Buzacott, 2000)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 18
Ch a pt er 3: Organizational Structure of Service Systems
Figure 3.5 displays the top-down structure. By the time work arrives a worker takes
on the responsibility performing all the diagnostic tasks and identifying the required
actions for delivering the service. Then he assigns work to a specialized server based
on the outcome of his diagnosis (worker 2 or 3).
Buzacott (2000) presented a taxonomy for classifying service systems (see Figure
3.6). The matrix consists of two dimensions: the nature of the service offering and the
corresponding service system structure. Buzacott’s classification resembles the wellknown Hayes and Wheelwright (1979) product-process matrix in manufacturing.
Thus, for a proper alignment between the product and the process, and the associated
gains in performance, service firms are advised to position their choice near the
diagonal. Furthermore, Buzacott’s matrix also recommends a movement up the
diagonal (simplification of the process) as the service evolves towards maturity.
Figure 3.6: Classification of service system structures
Source: “Service System Structure”, (Buzacott, 2000)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 19
Ch a pt er 3: Organizational Structure of Service Systems
The factors influencing the choice of the appropriate service delivery structure,
according to Buzacott (2000), are presented in Table 3.2. For the first level of
complexity, where the requirements of all customers are the same so that no diagnosis
is required and service tasks are relatively simple, a series structure seems sufficient.
As the complexity of tasks or the unpredictability of customers’ arrivals increases, a
parallel structure is preferable to deal with the extra variability in the system.
Following, as the service breadth extends and the differences in customer
requirements become substantial but at the same time customers are capable to
recognize what type of service they require, the system can be structured to specialize
by customer type with diagnosis taking a short period of time (i.e. instantaneous
diagnosis). The final step in structure complexity occurs when customers are no more
capable of selecting the type of service that suits them. Thus, service delivery requires
diagnosis. If diagnosis is relatively simple then diagnostic steps can be allocated to a
number of workers and system can take on a bottom-up structure. On the other hand,
if diagnosis is complex a top-down structure is preferable.
Based on these factors a firm may decide the appropriate structure for its process.
Although, the factors and the approach provide great insight, we argue that there are
some points of attention when using them.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 20
Ch a pt er 3: Organizational Structure of Service Systems
Table 3.2: Factors and values for deciding on the appropriate service delivery structure
Firstly, in Buzacott’s classification, the positioning of the service offering is based on
a predefined and limited number of design factors. However, service operations are
characterized by a multitude of design factors, with several interactions across
different domains. Secondly, service systems in reality encompass offerings with
“mixed” characteristics (diagnosis required, standard services, etc.); thus a unified
approach is difficult to apply. This is consistent with Apte et al. (1999), who note that
the optimal decision for an organization may be a mixed approach, with some part of
organization using one approach and the remaining using another.
3.4. Hybrid Service Structures
In this Section we present alternative delivery structures from the service operations
literature that comprise combinations of the previously reported structures.
3.4.1. The Case Manager Approach
The need for greater customization and responsiveness has led companies to come up
with a new work design model called the “case management approach”. Case
management is akin to a parallel service delivery structure; the key difference is that
in many situations the case manager’s role is limited to overseeing the entire cycle of
activities acting as a liaison between customers and the work performed by the firm’s
functions. A case manager is capable of creating and delivering an entire service from
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 21
Ch a pt er 3: Organizational Structure of Service Systems
start to finish providing a single point of contact for customers. Empowered by
information technology systems, case managers can draw on information from an
entire organization to make independent decisions and address customer needs
efficiently (Davenport and Nohria, 1994).
According to Apte et al. (1999), the case management approach has proven to be an
effective alternative for service firms to raise both their level of customization and
responsiveness. Presenting a single point of contact enables customers to interact with
the server in a more convenient and personalized way, avoiding unnecessary handoff
of work. Case managers, work autonomously taking full responsibility of the delivery,
and hence, can address customers’ imposed variability in a more efficient way adding
to the systems responsiveness. In conclusion, the case management approach shares
the same advantages and drawbacks with a parallel structure.
3.4.2. Service Cells
The concept of cellular manufacturing has occupied a prominent position in the
operations management literature. Cells are based on the grouping of dissimilar
machines or processes, required for the production of a specific family of parts with
similar shapes, tooling requirements or routings, into clusters (modules). Some of the
advantages associated with a cellular arrangement, as cited in the operations
management literature, include reduced flow times and less work-in-process (Shafer
and Charnes, 1993; Assad et al., 2003), reduced move time of parts (Assad et al.,
2003), higher machine utilization and job satisfaction (Tompkins, et al. 2003; Black,
2007).
The applications of service cells in the operations management literature are limited.
Swank (2003) presented a Life Insurance Company that managed to reduce its
turnaround time and cut costs by implementing (amongst other) cellular design. Pagell
and Melnyk (2004) applied service cells in one of the American Red Cross facilities.
The cells turned out to be more flexible, allowing the system to adjust to demand
fluctuations, and process faster the different types of donors. More recently, Hameri
(2011) formed service cells for the back-office processing of a large insurance
company, using production flow analysis (PFA). His results reported over 70% lead
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 22
Ch a pt er 3: Organizational Structure of Service Systems
time reduction, 70% reduction of work-in-process, lower process variability and
higher employee satisfaction.
The majority of applications of cellular manufacturing in services, concentrate in the
advantages and benefits gained, while they do not provide a systematic approach for
the efficient implementation of cells. Furthermore, most of the approaches are mostly
derived from manufacturing with limited adaptation to the unique nature of service
operations.
In the following sections we build further on the literature presented in this Chapter,
and create a systematic approach for designing service cells and ultimately deciding
on the appropriate service structure. In doing so, we use the Design Structure Matrix
methodology that will be presented in the next Chapter.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 23
Ch a pt er 4: The Design Structure Matrix
4. The Design Structure Matrix
Managing Complexity in operational environments is a key imperative. As an
indication, according to Lindemann et al. (2009), there are four aspects of complexity
in product development: a) market, i.e. complexity derived from market segments and
their unique characteristics, b) product, i.e. complexity derived from the product
specifications and attributes, c) process, i.e. complexity derived from the processes
used to deliver products or services, and d) organization, i.e. complexity related to
structure of people and teams across the organization. These areas of complexity are
mutually connected with dependencies and interrelations, which form structures that
drive systems behavior (Danilovic and Browning, 2007). These aspects exist in most
industries. However service operations are affected by additional factors, such as
those described in Chapter 3, that force them to form more complex structures.
By analyzing how service system elements interrelate and connect to each other
(based on the unique characteristics and factors presented earlier in Chapter 3),
managers could assess service system structures and eventually deal with the imposed
complexity. Nonetheless systems are typically comprised be hundreds of elements
that interrelate and depend on each other within each domain but also across other
domains. Modeling and analyzing such systems can become a frustrating task for
managers.
Design Structure Matrix (DSM) methodology has proven to be an effective way of
modeling, visualizing and analyzing how different organizational entities interrelate
and influence each other. It provides an efficient way of mapping system relationships
among components, teams or activities in a compact, visual and analytically format.
This analysis may enable to improve the structure of complex systems. Thus, below
we investigate how the Design Structure Matrix may be used for systematically
modeling and analyzing the structure of service systems.
4.1. Literature Review
Over the past 30 years several matrix-based approaches have been used in system
modeling and analysis, and especially in product design and development, project
management, and organizational design. Steward (1981) using binary matrices and
realignment algorithms, analyzed the structure of a system’s design process and
identified potentials of rework in the sequencing of the design tasks. McCord and
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 24
Ch a pt er 4: The Design Structure Matrix
Eppinger (1993) investigated the interactions between product components and
reorganized the structure of system development teams. Pimmler and Eppinger (1994)
presented a methodology for handling design decompositions. Using an interaction
quantification scheme, they documented interactions between decomposed system
elements of an automotive climate control system process and clustered them into
“chunks” of mutually interrelated components. As a result, design complexity was
reduced and coordination across large development teams was improved.
More
recently, Lindemann et al., (2009) presented new ways for handling Multiple Domain
Matrices, which alleviated and further improved the mapping and analysis of element
dependencies across different domains of a system.
Existing literature sums up to three types of matrix-based methods. The Design
Structure Matrix (DSM) used for representation and analysis of dependencies between
elements of the same type (e.g. dependencies between product components), the
Domain Mapping Matrix (DMM) for mapping of relations of elements of two
different types (e.g. mapping dependencies between product component and
development teams), and the Multiple Domain Matrix (MDM) for an aggregated
approach of the previous methodologies. These matrix types are analyzed below.
4.2. Types of Matrix-based Methods
4.2.1. Design Structure Matrix (DSM)
The Design Structure Matrix methodology is used to handle dependencies in a single
domain and hence, it uses intra-domain matrices (for e.g. process tasks, development
teams, etc.). The term “Design Structure Matrix” was coined by Steward (1981); in
this reference he used matrix-based techniques to analyze the design process of a
system. However, in the literature there are other references to this type of matrix,
such as Dependency Structure Matrix, Incidence Matrix, Dependency Map.
DSM is a square matrix, i.e., containing equal number of rows and columns. Both the
rows and columns of the matrix represent the system elements, with each off-diagonal
mark representing a dependency of one element to another (see Figure 4.1) Reading
across a row reveals to which other element, the element of that row, provides
outputs; reading below a column reveals from which other element of the system the
element of that column receives inputs.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 25
Ch a pt er 4: The Design Structure Matrix
For example, consider the system network in the left side of Figure 4.1. In the DSM
representation, system element B receives inputs from elements A, C and D and
provides outputs to elements A and D. In the above example, element dependencies
are represented in a binary form (i.e. the DSM contains only zeros and ones).
Although a binary matrix is sufficient for representing the existence and the direction
of the dependency, for more detailed analysis on the relationships between the
elements, numerical DSMs may be more powerful. Numbers in the matrix may
represent the weight of the interaction, values of an attribute or even probability of
repetition.
Representation
in DSM
Figure 4.1: Representation of system’s dependencies in DSM
According to Browning (2001), DSMs are divided into the following two major
categories:
•
Static
DSMs
are
matrices
representing
system
elements
existing
simultaneously in the system, such as components of the product or product
development teams. Generally, in static DSM approaches the goal is to cluster
highly interdependent elements into modules while minimizing the
interactions between clusters.
•
Time-based matrices represent flow through time. Thus, interactions below
the diagonal indicate a feed-forward, whereas, interactions above the diagonal
indicate a feedback. For time-based DSMs the overall goal is to lowertriangularize the matrix, or otherwise get as many upper-diagonal marks as
close to the diagonal as possible, so that feedback loops are minimized. Time-
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 26
Ch a pt er 4: The Design Structure Matrix
based matrices are generally used in new product development projects where
interaction feedback loops are constant (for additional applications of timebased matrices refer to Browning, 2001).
Browning (2001), identified four DSM applications of Static and Time-based
matrices:
1. Component-based DSM: Used for modeling the product architecture and
enhancing modularity
2. Team-based DSM: Used for modeling the organization structure and
facilitating communication across system teams
3. Activity-Based DSM: Used for modeling activity networks with the aim of
minimizing the time and feedback loops of the overall process
4. Parameter-Based DSM: Used for modeling low-level design parameter
relationships.
4.2.2. Domain Mapping Matrix (DMM)
Contrary to Design Structure Matrices, which consider only one domain of the
system, Domain Mapping Matrices constitute rectangular, inter-domain matrices (i.e.
matrices that map the elements of one domain to another); this extends the efficacy of
DSM. Various studies applied DMM to document the relationships between product
architecture and organization (Danilovic & Börjesson, 2001), and to analyze customer
requirements against product specifications (Danilovic and Browning, 2007). As an
example of DMMs application, consider the allocation of process tasks to employees
presented in the left side of Figure 4.2. In the graph tasks 1 and 2 are performed by
employee A, 3 and 5 by employee B, and employee C performs task 4. This structure
can be easily transferred in a DMM by simply assigning workers and tasks in the rows
and columns of the matrix respectively (Figure 4.2). Reading across the rows reveals
the tasks performed by the worker of the corresponding row, while reading below a
column reveals which worker performs the corresponding task..
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 27
Ch a pt er 4: The Design Structure Matrix
Representation
in DMM
Figure 4.2: Representation of inter-domain dependencies in DMM
4.2.3. Multiple Domain Matrix (MDM)
The DSM and DMM approaches have been extended to enable the modeling and
analysis of entire systems, spanning multiple domains, into a new aggregated view,
the Multiple Domain Matrix (Lindemann, et al., 2009). A Multiple Domain Matrix
(MDM) is basically a large Design Structure Matrix comprised of the system’s intradomain relationships stored in DSMs across the diagonal with the system’s interdomain dependencies accumulated in off-diagonal DMMs. Hence, the MDM can act
as an aggregated DSM that facilitates system structure analysis across multiple
domains. An MDM, just like a DSM, can be binary or numerical. Furthermore,
system analysis can be performed, through the use of appropriate algorithms, across
several domains.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 28
Ch a pt er 4: The Design Structure Matrix
Figure 4.3: System network representation in a Multiple Domain Matrix
Source: “Structural Complexity Management”, (Lindemann, et al., 2009)
Figure 4.3 from Lindermann et al. (2009) shows an example of a system network
consisting of eleven elements belonging to three different domains. Individual
domains are represented by circles, triangles and squares in order to distinguish them.
Moreover, four dependency types indicated by the different lines connect the eleven
elements. The domains could represent, for example, components, people, and data.
Dependency types could represent change impact, information flow, or geometric
dependencies. Such a network can be transformed into an MDM that contains the
system elements and represents their intra-domain and inter-domain relationships in
individual DSMs and DMMs, respectively. In order to further clarify this, consider
Figure 4.4. Here only the subsets of intra-domain dependencies are considered, and
hence, four separate DSMs have to be employed for capturing the four distinct
relationships across the three individual domains. In this example, in the domain
represented by triangular shapes, two types of dependencies occur, and, thus, two
separate matrices have to be used to address these dependencies.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 29
Ch a pt er 4: The Design Structure Matrix
Figure 4.4: Intra-domain dependencies representation in DSMs
Source: “Structural Complexity Management”, (Lindemann et al., 2009)
In Figure 4.5 only the subsets of inter-domain dependencies are depicted. Thus, in
order to systematically capture the dependencies between different domains, four
DMM have been used. Again, since two types of dependencies occur between the
circular and triangular domains, separate DMM matrices have been used to represent
them.
Figure 4.5: Inter-domain dependencies representation in DMMs
Source: “Structural Complexity Management”, (Lindemann, iet al., 2009)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 30
Ch a pt er 4: The Design Structure Matrix
The matrix at the right side of Figure 4.3 illustrates how individual DSM representing
the different intra-domain and inter-domain dependencies are transferred into the final
Multiple Domain. All DSM containing intra-domain dependencies are laid across the
diagonal, while the DMM containing inter-domain dependencies serve as links
represented in the off-diagonal block areas of the matrix. Each DSM and DMM can
only represent one specific dependency type, and thus, separate matrices should be
developed within the same MDM area in order to map all system dependencies. The
separate matrices are visually laid one behind the other in the example of Figure 4.3.
4.3. System Structure Analysis
As mentioned above, the Design Structure Matrix is an advantageous way of
representing system elements and mapping their relationships in a compact, visual and
efficient way. However, DSM’s advantage stems from the fact that matrices can be
further analyzed, using computational algorithms and heuristics that facilitate the
study of the system in question. Suitable analysis may reveal the elements and subsets
of the system, thereconfiguration or adjustment of which may improve system
performance radically.
The choice of the appropriate algorithm depends on the objective of the analysis.
Generally, for Static DSMs, where the aim is to identify independent modules of
system elements with significant internal dependencies, clustering algorithms are
preferred. On the contrary, for Time-based DSMs, where the objective is the proper
sequencing of the design process, a partitioning algorithm may be more advantageous.
In both cases, however, the objective of the analysis is the realignment of the elements
of the matrix so that significant structural characteristics of the system in question
become apparent. In the literature, one may find several methods for the analysis of
the DSM. Some of the most significant among them are discussed below.
4.3.1. Clustering
The objective of clustering analysis is to identify subsets of DSM elements that are
highly dependent, and assign them to clusters while trying to maintain low external
dependencies between individual clusters. Thus, a change in one of the elements
assigned to a cluster will have a minimum impact on elements corresponding to
different clusters. Furthermore, in dynamic networks (e.g. a network that consists of
jobs within a service process), elements belonging to a cluster can be executed in
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 31
Ch a pt er 4: The Design Structure Matrix
parallel (i.e. simultaneously). Consequently, clusters represent the basis for creating
modules.
For example, consider the DSM of Figure 4.6, in which Pimmler and Eppinger (1994)
using a component-based DSM mapped and analyzed the product architecture of an
automobile climate control system.
Figure 4.6: Component-based matrix of an automobile climate control system
Source: “Integration analysis of system decompositions”, (Pimmler & Eppinger, 1994)
Subsequently using a distance penalty algorithm they reordered the rows and columns
of the matrix, forming clusters or mutually interrelated components along the matrix
diagonal (Figure 4.7).
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 32
Ch a pt er 4: The Design Structure Matrix
Figure 4.7: Clustered matrix of the component-based DSM
Source: “Integration analysis of system decompositions”, (Pimmler & Eppinger, 1994)
This procedure succeeded in improving the climate control’s product design and
supported further modularization.
In literature there have been several algorithms and heuristics for the computational
analysis of the DSM matrices. Indicative examples include, the clustering algorithms
of Andrew Kusiak (1993), Carlos Inaki Gutierrez Fernandez (1998) and more recently
Ronnie Thebeau (2001). For our approach (presented in the next chapter) we chose
the clustering algorithm of Ronnie Thebeau (for details refer to Appendix A).
4.3.2. Partitioning, banding and tearing
In addition to clustering, several other computational algorithms have been employed
in the literature to analyze the DSM. Among them partitioning, banding and tearing
(for a detailed analysis refer to Appendix B).
4.4. Limitations of the DSM
In the previous chapter the different types of Design Structure Matrices were
presented for the systematic representation of complex systems for one or multiple
domains. However, it is equally important to highlight the limitations as well as points
of attention when using this methodology.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 33
Ch a pt er 4: The Design Structure Matrix
The construction of the DSM and its usefulness depends on the selection of the
domains that impact the system. By selecting certain domains over others, we focus
on selected structural views of the system. In Figure 4.8, for example, we applied a
clustering algorithm for the realignment of the matrix based on one domain. The
result might be different if we had selected different domains.
In addition, the results of the clustering depend on the algorithm used, i.e. different
algorithms produce different results. Thus, the choice of the appropriate algorithm is
of significance. In many cases the application of a realignment algorithm is not
enough; some characteristics of the system’s structure become evident only by graph
representation of the dependencies (Lindemann et al., 2009).
Figure 4.8: Structural characteristics depiction by realignment of the DSM
The construction of the DSM alone is a complex and time-consuming process. As
Browning states “individuals may have difficulty building DSMs with more than ten
elements” (Browning, 2001). Thus, users need to follow a consistent approach that
will assure high quality of the inter-relationship data. Data acquisition could either be
accomplished through interviews with experts or using existing data sets. Efficient
data acquisition would prevent misleading results concerning the structure of the
system.
Additionally, besides the direct dependencies of system elements, the user should also
take into account possible indirect ones that may not be apparent. This is explained
with an example in Figure 4.9. In the system of Fig. 4.9, person’s A with person’s B
interdependency, due to information exchange for instance, is defined as a direct
dependency and can be easily picked from interviews or available process data.
However, in this particular example the two people retain an additional “indirect”
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 34
Ch a pt er 4: The Design Structure Matrix
dependency (indicated by the dashed line) as they work on different but mutually
linked system components. Such a relation may not be evident due to the system’s
complexity or the persons’ unawareness of its existence. The methodology for
deriving additional matrices for the systematic mapping of indirect system
dependencies is presented in Appendix C.
Figure 4.9: Indirect dependency depiction between two persons due to component interrelation
The manipulation of the matrices can also be a confusing procedure. Users may be
forced to run the selected algorithm several times before getting the requisite results.
From our experience the construction and analysis of the DSM is an iterative process.
We strongly recommend that users follow a trial and error approach until they get
acquainted with this methodology.
Finally, the use of specialized computer software can significantly facilitate the whole
process. For our case, we used the mathematical package Matlab. We chose this
software for several reasons. Matlab is designed to work well with matrices and
proved to be an efficient tool for dealing with the indirect system dependencies. In
addition, for our approach we chose to employ the clustering algorithm of Thebeau
(2001) that was developed in Matlab environment.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 35
Ch a pt er 5: Methodology followed and Case Study
5. Methodology followed and Case Study
In this Chapter we adapt and apply the methodology of Lindermann et al. (1999)
described in the previous Chapter, in order to assess different organization structures
in financial services. We first outline the methodology of Lindermann et al.
Subsequently, we define the case study environment used for our work. Finally, we
describe the methodology in detail, its application and adaptation through the
significant case study.
5.1. Methodology Overview
Our proposed approach has been based upon the “Structural Complexity
Management” method for managing complex systems (Lindemann et. al., 1999) and
is summarized in Table 5.1. In this table, we provide a short description of each step.
In Section 5.3 we present a thorough description of each step and the related
adaptations to fit the unique service environment.
Table 5.1: Procedure of Structural Complexity Management
Step
Structural Complexity Management
Description
Approach
1.
System Definition
Define and select appropriate domains and their
relationships for system analysis
2.
Information Acquisition
Collection of information on system element
dependencies
3.
Deduction of Indirect Dependencies
Determination of indirect dependencies based on
available computation cases
4.
Structure Analysis
Identification and analysis of system’s structural
characteristics
5.
Product Design Application
Discussion of results and submit suggestions on
system improvements
Source: “Structural Complexity Management”, (Lindemann et al., 2009)
5.2. Case Study Environment
We applied our approach to the back-office operations of a European organization
offering post-trade services. The company offers three distinct services to three
sizeable global markets: Market A, B and C; where it offers Services 1, 2 and 3 for
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 36
Ch a pt er 5: Methodology followed and Case Study
each market1. The swim-lanes of Figure 5.1, Figure 5.2 and Figure 5.3 demonstrate
the dependencies and flow of work and information between jobs for individual
services. Unintentional iteration and rework during the processes are mapped through
network probabilities for each step. Overall we identified 150 jobs; 42, 51 and 57 for
Services 1, 2 and 3 respectively.
1
For nondisclosure reason the full nature of the case study is withheld
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 37
Ch a pt er 5: Methodology followed and Case Study
Figure 5.1: Swim-lane of Service 1 jobs with network probabilities
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 38
Ch a pt er 5: Methodology followed and Case Study
Figure 5.2: Swim-lane of Service 2 jobs with network probabilities
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 39
Ch a pt er 5: Methodology followed and Case Study
Figure 5.3: Swim-lane of Service 3 jobs with network probabilities
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 40
Ch a pt er 5: Methodology followed and Case Study
The system’s jobs are grouped in different departments based on function similarity.
There are six key functions:
i) Client Service (CS), i.e. dealing with customers’ queries,
ii) Information Processing (INFO), i.e. processing information regarding
future events, such as corporate actions,
iii) Instruction Processing (INST), i.e. processing clients’ instructions,
regarding participation in corporate actions,
iv) Payments (PAY), i.e. processing clients’ payments,
v) Account Updates (AU), i.e. creating or updating new accounts for
instruments such as funds or equities,
vi) Reconciliation (REC), i.e. daily controls for ensuring proper treatment
of payments.
Table 5.2 below provides a list of the considered system elements from each domain.
As mentioned before the company operates in three individual Markets (i.e. the group
of consumers that the service is provided). The Markets are separated based on
demographical characteristics (location, operating time zone etc.). The organization
also offers three unique services (i.e. products) to its customers. Lastly, each service’s
jobs fulfill one of the six key functions of the third column in Table 5.2.
Table 5.2: System elements under consideration
Market
Services
Function
Market A
Service 1
CS
Market B
Service 2
INFO
Market C
Service 3
INST
PAY
AU
REC
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 41
Ch a pt er 5: Methodology followed and Case Study
The company’s administration, at the time, was looking for a way to deal with the
ever-growing complexity of their operations. Complexity was primarily due to
increasing system variants in the organization’s processes.
The company’s current structure was organized by function (i.e. a series structure
organized based on the similarity of task). That is, each department performed the
jobs corresponding to a specific function for all services and for all markets. This
structure faced several issues. Firstly, due to the handoff of work between functional
teams a lot of time was lost for re-examining the case. Secondly, the customer was not
effectively dispatched to the right process having to change multiple lines before
being properly served. Lastly, the grouping of employees in functional “silos”
affected coordination between teams, leading to undesired errors and rework.
Figure 5.1, Figure 5.2 and Figure 5.3 represent how work moves through functional
departments represented by the different parallel lines
The organization’s management, in order to address these issues, examined several
scenarios and came up with three predominant organizational structures. These three
organizational scenarios are presented in Figure 5.4.
Figure 5.4: Service organization structure scenarios 1-3 to be assessed
The first structure scenario of Figure 5.4 represents the current organizational
structure of the service firm. The vertical rectangles of the schematic imply that
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 42
Ch a pt er 5: Methodology followed and Case Study
departments are divided based on function and each functional department processes
all Services for all Markets. Following, in scenario 2 the parallel rectangles of the
schematic imply that the organizations are divide based on Service, and hence, each
department performs all functions for all Markets. Lastly, in scenario 3 departments
are divided by Market with each department capable of performing all functions for
all services.
5.3. Description, Application, and Adaptation of Methodology in the Financial
Services Case
5.3.1. System Definition
Our approach starts with the definition of the system, i.e. the selection of the system’s
critical domains and their relationships, which are mapped in the Multiple Domain
Matrix (MDM). Based on unique characteristics of the case study environment
overviewed in the previous section we selected the following domains:

Jobs, since the formation of departments and thus the configuration of the
organization depend largely on the structure of the process jobs. Here Job is
defined as a step or part of the overall service. E.g. answering to customer
queries or updating customer’s account. Hence, a service is comprised by a
number of different jobs.

Market, since each market exhibits unique requirements. Markets can be
formed based on the type of customers, operating time zones, location etc. For
our case, markets are homogeneous and are geographically distributed.

Service, since in service operations the end product is the service itself.

Function, since the type of function each job serves plays a decisive role in
work organization.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 43
Ch a pt er 5: Methodology followed and Case Study
MARKET
SERVICE
JOB
FUNCTION
MARKET
Market has
influence on
Market
Markets request
specific Services
---
---
SERVICE
---
Service depends
on Service
---
---
Job varies
according to the
Market
(1)
Services are
produced through
Jobs
(2)
Job has influence
on Job
(3)
---
---
---
JOB
FUNCTION
Jobs belong to
different
Functions
(4)
Function requires
Function
Figure 5.5: Domains and types of dependencies in the MDM
For each domain, we identified its relationships with other domains. Based on the
interviews with experts on the field, we focused our analysis on the most important
relationships presented below (grey boxes 1-4, in Figure 5.5):
1. Job varies according to the Market; this relationship implies that each job is
differentiated in terms of content, sequence and timing according to the
specific rules of operation in each market. For example US versus Asian
markets operate under different time zones, follow different rules and the
documentations significantly vary.
2. Services are produced through Jobs; the intangible nature of services implies
that services are produced through a series of jobs. Hence, in our example
each service is connected to the jobs that are needed in order to produce it.
3. Job has influence on Job; this refers to the information relation and flow
between jobs of the service process.
4. Jobs belong to different Functions; this relationship implies that different jobs
serve different functions of the system. For example, all jobs that require
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 44
Ch a pt er 5: Methodology followed and Case Study
customer contact, either for answering queries or requesting additional
information, are performed by client services (CS).
5.3.2. Information Acquisition
Generally there are two approaches available for information acquisition. Information
can be obtained from available data sets or may be extracted through interviews with
experts. In both cases the user should pay significant attention to the way the
information is collected in order to ensure the quality of the captured data. The aim is
to identify and document the critical dependencies between the elements within all the
domains of the system. This step is extremely important for the overall method, since
any deficiencies in acquisition can jeopardize the results of the analysis.
During this step we collected quantifiable data (for all the available data refer to
Appendix D). For each service, the average demand for a period of nine months was
captured, as well as data for the Average Process Time and the Learning Curve for
each Job. It is reasonable to expect that each job affects another in a different way (i.e.
some interactions between activities will be stronger than others). Thus, in our model
each off-diagonal dependency between jobs reflects the strength and criticality of the
interaction based on the following equation:
DSMij = Pr obability _ of _ occurenceij *Workload j
where,
i.
Probability_of_occurenceij: The probability of moving from job i to job j
ii.
Workloadj: The average workload of job j. This is given from the following
equation,
Workload j =
Volume j * Duration j
FTEs
where,
a. Volumej: The average monthly demand for job j
b. Durationj: The average time to complete job j
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 45
Ch a pt er 5: Methodology followed and Case Study
c. Full Time Equivalents (FTE): The total time of hours a full time
worker has spend working a day
Next, we used the swim-lane models of Section 5.3.1 and built the “target” Job-Job
matrix (hereafter Process matrix). To do this, we transformed the existing flow of
work and information from all three swim-lane diagrams into a 150 x 150 DSM
matrix using the probabilities for related path method (the available methodologies for
converting processes logics into matrices are presented in Appendix E) Figure 5.6
demonstrates the dependencies across all jobs of the system.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 46
1
EN_Voluntary_19_Receive, Analyze & Send_Problem_NI
EN_Voluntary_15_Forward_Info Payments_PAY
EN_Voluntary_16_Send Reply_Info Payments_CS
EN_Voluntary_17_Process & Send (All)_Cleaning_PAY
1
EN_Voluntary_18_Receive, Analyze & Send_Problem_REC
EN_Voluntary_14_Process & Send _Payment_PAY
EN_Voluntary_13_Receive, Analyze & Send_Problem_REC
EN_Voluntary_9_Forward_Answer_CS
EN_Voluntary_11_Forward_Instruction_INST
EN_Voluntary_12_Process & Send (All)_Reconciliation_PAY
EN_Voluntary_7_Forward_Question_CS
EN_Voluntary_10_Process & Send _Instruction_INST
EN_Voluntary_8_Receive, Analyze & Send_Question_INFO
EN_Voluntary_3_Create_Code_NI
EN_Voluntary_6_Send Reply_Question_CS
EN_Voluntary_4_Process & Send _Event_INFO
EN_Voluntary_2_Request_Code Creation_INFO
EN_Voluntary_5_Receive & Analyze_Question_CS
EN_Voluntary_1_Receive, Analyze & Send_Info_INFO
UK_Voluntary_19_Receive, Analyze & Send_Problem_NI
UK_Voluntary_18_Receive, Analyze & Send_Problem_REC
UK_Voluntary_15_Forward_Info Payments_PAY
UK_Voluntary_16_Send Reply_Info Payments_CS
UK_Voluntary_17_Process & Send (All)_Cleaning_PAY
UK_Voluntary_14_Process & Send _Payment_PAY
UK_Voluntary_13_Receive, Analyze & Send_Problem_REC
UK_Voluntary_9_Forward_Answer_CS
UK_Voluntary_11_Forward_Instruction_INST
UK_Voluntary_12_Process & Send (All)_Reconciliation_PAY
UK_Voluntary_7_Forward_Question_CS
UK_Voluntary_10_Process & Send _Instruction_INST
UK_Voluntary_8_Receive, Analyze & Send_Question_INFO
UK_Voluntary_3_Create_Code_NI
UK_Voluntary_6_Send Reply_Question_CS
UK_Voluntary_4_Process & Send _Event_INFO
UK_Voluntary_2_Request_Code Creation_INFO
UK_Voluntary_5_Receive & Analyze_Question_CS
UK_Voluntary_1_Receive, Analyze & Send_Info_INFO
1
DR_Voluntary_19_Receive, Analyze & Send_Problem_NI
1
DR_Voluntary_18_Receive, Analyze & Send_Problem_REC
DR_Voluntary_15_Forward_Info Payments_PAY
DR_Voluntary_16_Send Reply_Info Payments_CS
DR_Voluntary_17_Process & Send (All)_Cleaning_PAY
DR_Voluntary_14_Process & Send _Payment_PAY
DR_Voluntary_13_Receive, Analyze & Send_Problem_REC
DR_Voluntary_9_Forward_Answer_CS
DR_Voluntary_11_Forward_Instruction_INST
DR_Voluntary_12_Process & Send (All)_Reconciliation_PAY
DR_Voluntary_7_Forward_Question_CS
DR_Voluntary_10_Process & Send _Instruction_INST
DR_Voluntary_8_Receive, Analyze & Send_Question_INFO
DR_Voluntary_3_Create_Code_NI
DR_Voluntary_6_Send Reply_Question_CS
DR_Voluntary_4_Process & Send _Event_INFO
DR_Voluntary_2_Request_Code Creation_INFO
DR_Voluntary_5_Receive & Analyze_Question_CS
DR_Voluntary_1_Receive, Analyze & Send_Info_INFO
1
EN_Mandatory_17_Receive, Analyze & Send_Problem_NI
1
EN_Mandatory_16_Receive, Analyze & Send_Problem_REC
EN_Mandatory_13_Forward_Info Payments_PAY
EN_Mandatory_14_Send Reply_Info Payments_CS
EN_Mandatory_15_Process & Send (All)_Cleaning_PAY
EN_Mandatory_9_Forward_Answer_CS
EN_Mandatory_12_Process & Send _Payment_PAY
EN_Mandatory_11_Receive, Analyze & Send_Problem_REC
EN_Mandatory_7_Forward_Question_CS
EN_Mandatory_8_Receive, Analyze & Send_Question_INFO
EN_Mandatory_10_Process & Send (All)_Reconciliation_PAY
EN_Mandatory_3_Create_Code_NI
EN_Mandatory_6_Send Reply_Question_CS
EN_Mandatory_4_Process & Send _Event_INFO
EN_Mandatory_5_Receive & Analyze_Question_CS
EN_Mandatory_1_Receive & Analyze_Info_INFO
EN_Mandatory_2_Request_Code Creation_INFO
UK_Mandatory_17_Receive, Analyze & Send_Problem_NI
UK_Mandatory_16_Receive, Analyze & Send_Problem_REC
UK_Mandatory_13_Forward_Info Payments_PAY
UK_Mandatory_14_Send Reply_Info Payments_CS
UK_Mandatory_15_Process & Send (All)_Cleaning_PAY
UK_Mandatory_9_Forward_Answer_CS
UK_Mandatory_12_Process & Send _Payment_PAY
UK_Mandatory_11_Receive, Analyze & Send_Problem_REC
UK_Mandatory_7_Forward_Question_CS
UK_Mandatory_8_Receive, Analyze & Send_Question_INFO
UK_Mandatory_10_Process & Send (All)_Reconciliation_PAY
UK_Mandatory_3_Create_Code_NI
UK_Mandatory_6_Send Reply_Question_CS
UK_Mandatory_4_Process & Send _Event_INFO
UK_Mandatory_5_Receive & Analyze_Question_CS
UK_Mandatory_1_Receive & Analyze_Info_INFO
UK_Mandatory_2_Request_Code Creation_INFO
1
DR_Mandatory_17_Receive, Analyze & Send_Problem_NI
DR_Mandatory_13_Forward_Info Payments_PAY
DR_Mandatory_14_Send Reply_Info Payments_CS
DR_Mandatory_15_Process & Send (All)_Cleaning_PAY
1
DR_Mandatory_16_Receive, Analyze & Send_Problem_REC
DR_Mandatory_9_Forward_Answer_CS
DR_Mandatory_12_Process & Send _Payment_PAY
DR_Mandatory_11_Receive, Analyze & Send_Problem_REC
DR_Mandatory_7_Forward_Question_CS
DR_Mandatory_8_Receive, Analyze & Send_Question_INFO
DR_Mandatory_10_Process & Send (All)_Reconciliation_PAY
DR_Mandatory_3_Create_Code_NI
DR_Mandatory_6_Send Reply_Question_CS
DR_Mandatory_4_Process & Send _Event_INFO
DR_Mandatory_2_Request_Code Creation_INFO
DR_Mandatory_5_Receive & Analyze_Question_CS
EN_Meetings_12_Forward_Instruction_CS
DR_Mandatory_1_Receive & Analyze_Info_INFO
EN_Meetings_14_Process & Send _Instruction_INST
EN_Meetings_13_Request_Instruction Documentation_CS
EN_Meetings_11_Receive, Analyze & Send_Instruction_INFO
EN_Meetings_8_Forward_Answer_CS
EN_Meetings_10_Forward_Instruction_INST
EN_Meetings_9_Receive & Analyze_Instruction_INST
EN_Meetings_6_Forward_Question_CS
EN_Meetings_5_Send Reply_Question_CS
EN_Meetings_7_Receive, Analyze & Send_Question_INFO
EN_Meetings_3_Process & Send _Event_INFO
EN_Meetings_4_Receive & Analyze_Question_CS
EN_Meetings_2_Request_Info Clarification_INFO
UK_Meetings_12_Forward_Instruction_CS
EN_Meetings_1_Receive & Analyze_Info_INFO
UK_Meetings_14_Process & Send _Instruction_INST
UK_Meetings_13_Request_Instruction Documentation_CS
UK_Meetings_8_Forward_Answer_CS
UK_Meetings_10_Forward_Instruction_INST
UK_Meetings_11_Receive, Analyze & Send_Instruction_INFO
UK_Meetings_6_Forward_Question_CS
UK_Meetings_9_Receive & Analyze_Instruction_INST
UK_Meetings_5_Send Reply_Question_CS
UK_Meetings_7_Receive, Analyze & Send_Question_INFO
UK_Meetings_3_Process & Send _Event_INFO
UK_Meetings_4_Receive & Analyze_Question_CS
UK_Meetings_2_Request_Info Clarification_INFO
DR_Meetings_12_Forward_Instruction_CS
UK_Meetings_1_Receive & Analyze_Info_INFO
DR_Meetings_14_Process & Send _Instruction_INST
DR_Meetings_13_Request_Instruction Documentation_CS
DR_Meetings_8_Forward_Answer_CS
DR_Meetings_10_Forward_Instruction_INST
DR_Meetings_11_Receive, Analyze & Send_Instruction_INFO
DR_Meetings_6_Forward_Question_CS
DR_Meetings_9_Receive & Analyze_Instruction_INST
DR_Meetings_5_Send Reply_Question_CS
DR_Meetings_7_Receive, Analyze & Send_Question_INFO
DR_Meetings_3_Process & Send _Event_INFO
DR_Meetings_4_Receive & Analyze_Question_CS
DR_Meetings_1_Receive & Analyze_Info_INFO
DR_Meetings_1_Receive & Analyze_Info_INFO
DR_Meetings_2_Request_Info Clarification_INFO
DR_Meetings_3_Process & Send _Event_INFO
DR_Meetings_4_Receive & Analyze_Question_CS
DR_Meetings_5_Send Reply_Question_CS
DR_Meetings_6_Forward_Question_CS
DR_Meetings_7_Receive, Analyze & Send_Question_INFO
DR_Meetings_8_Forward_Answer_CS
DR_Meetings_9_Receive & Analyze_Instruction_INST
DR_Meetings_10_Forward_Instruction_INST
DR_Meetings_11_Receive, Analyze & Send_Instruction_INFO
DR_Meetings_12_Forward_Instruction_CS
DR_Meetings_13_Request_Instruction Documentation_CS
DR_Meetings_14_Process & Send _Instruction_INST
UK_Meetings_1_Receive & Analyze_Info_INFO
UK_Meetings_2_Request_Info Clarification_INFO
UK_Meetings_3_Process & Send _Event_INFO
UK_Meetings_4_Receive & Analyze_Question_CS
UK_Meetings_5_Send Reply_Question_CS
UK_Meetings_6_Forward_Question_CS
UK_Meetings_7_Receive, Analyze & Send_Question_INFO
UK_Meetings_8_Forward_Answer_CS
UK_Meetings_9_Receive & Analyze_Instruction_INST
UK_Meetings_10_Forward_Instruction_INST
UK_Meetings_11_Receive, Analyze & Send_Instruction_INFO
UK_Meetings_12_Forward_Instruction_CS
UK_Meetings_13_Request_Instruction Documentation_CS
UK_Meetings_14_Process & Send _Instruction_INST
EN_Meetings_1_Receive & Analyze_Info_INFO
EN_Meetings_2_Request_Info Clarification_INFO
EN_Meetings_3_Process & Send _Event_INFO
EN_Meetings_4_Receive & Analyze_Question_CS
EN_Meetings_5_Send Reply_Question_CS
EN_Meetings_6_Forward_Question_CS
EN_Meetings_7_Receive, Analyze & Send_Question_INFO
EN_Meetings_8_Forward_Answer_CS
EN_Meetings_9_Receive & Analyze_Instruction_INST
EN_Meetings_10_Forward_Instruction_INST
EN_Meetings_11_Receive, Analyze & Send_Instruction_INFO
EN_Meetings_12_Forward_Instruction_CS
EN_Meetings_13_Request_Instruction Documentation_CS
EN_Meetings_14_Process & Send _Instruction_INST
DR_Mandatory_1_Receive & Analyze_Info_INFO
DR_Mandatory_2_Request_Code Creation_INFO
DR_Mandatory_3_Create_Code_NI
DR_Mandatory_4_Process & Send _Event_INFO
DR_Mandatory_5_Receive & Analyze_Question_CS
DR_Mandatory_6_Send Reply_Question_CS
DR_Mandatory_7_Forward_Question_CS
DR_Mandatory_8_Receive, Analyze & Send_Question_INFO
DR_Mandatory_9_Forward_Answer_CS
DR_Mandatory_10_Process & Send (All)_Reconciliation_PAY
DR_Mandatory_11_Receive, Analyze & Send_Problem_REC
DR_Mandatory_12_Process & Send _Payment_PAY
DR_Mandatory_13_Forward_Info Payments_PAY
DR_Mandatory_14_Send Reply_Info Payments_CS
DR_Mandatory_15_Process & Send (All)_Cleaning_PAY
DR_Mandatory_16_Receive, Analyze & Send_Problem_REC
DR_Mandatory_17_Receive, Analyze & Send_Problem_NI
UK_Mandatory_1_Receive & Analyze_Info_INFO
UK_Mandatory_2_Request_Code Creation_INFO
UK_Mandatory_3_Create_Code_NI
UK_Mandatory_4_Process & Send _Event_INFO
UK_Mandatory_5_Receive & Analyze_Question_CS
UK_Mandatory_6_Send Reply_Question_CS
UK_Mandatory_7_Forward_Question_CS
UK_Mandatory_8_Receive, Analyze & Send_Question_INFO
UK_Mandatory_9_Forward_Answer_CS
UK_Mandatory_10_Process & Send (All)_Reconciliation_PAY
UK_Mandatory_11_Receive, Analyze & Send_Problem_REC
UK_Mandatory_12_Process & Send _Payment_PAY
UK_Mandatory_13_Forward_Info Payments_PAY
UK_Mandatory_14_Send Reply_Info Payments_CS
UK_Mandatory_15_Process & Send (All)_Cleaning_PAY
UK_Mandatory_16_Receive, Analyze & Send_Problem_REC
UK_Mandatory_17_Receive, Analyze & Send_Problem_NI
EN_Mandatory_1_Receive & Analyze_Info_INFO
EN_Mandatory_2_Request_Code Creation_INFO
EN_Mandatory_3_Create_Code_NI
EN_Mandatory_4_Process & Send _Event_INFO
EN_Mandatory_5_Receive & Analyze_Question_CS
EN_Mandatory_6_Send Reply_Question_CS
EN_Mandatory_7_Forward_Question_CS
EN_Mandatory_8_Receive, Analyze & Send_Question_INFO
EN_Mandatory_9_Forward_Answer_CS
EN_Mandatory_10_Process & Send (All)_Reconciliation_PAY
EN_Mandatory_11_Receive, Analyze & Send_Problem_REC
EN_Mandatory_12_Process & Send _Payment_PAY
EN_Mandatory_13_Forward_Info Payments_PAY
EN_Mandatory_14_Send Reply_Info Payments_CS
EN_Mandatory_15_Process & Send (All)_Cleaning_PAY
EN_Mandatory_16_Receive, Analyze & Send_Problem_REC
EN_Mandatory_17_Receive, Analyze & Send_Problem_NI
DR_Voluntary_1_Receive, Analyze & Send_Info_INFO
DR_Voluntary_2_Request_Code Creation_INFO
DR_Voluntary_3_Create_Code_NI
DR_Voluntary_4_Process & Send _Event_INFO
DR_Voluntary_5_Receive & Analyze_Question_CS
DR_Voluntary_6_Send Reply_Question_CS
DR_Voluntary_7_Forward_Question_CS
DR_Voluntary_8_Receive, Analyze & Send_Question_INFO
DR_Voluntary_9_Forward_Answer_CS
DR_Voluntary_10_Process & Send _Instruction_INST
DR_Voluntary_11_Forward_Instruction_INST
DR_Voluntary_12_Process & Send (All)_Reconciliation_PAY
DR_Voluntary_13_Receive, Analyze & Send_Problem_REC
DR_Voluntary_14_Process & Send _Payment_PAY
DR_Voluntary_15_Forward_Info Payments_PAY
DR_Voluntary_16_Send Reply_Info Payments_CS
DR_Voluntary_17_Process & Send (All)_Cleaning_PAY
DR_Voluntary_18_Receive, Analyze & Send_Problem_REC
DR_Voluntary_19_Receive, Analyze & Send_Problem_NI
UK_Voluntary_1_Receive, Analyze & Send_Info_INFO
UK_Voluntary_2_Request_Code Creation_INFO
UK_Voluntary_3_Create_Code_NI
UK_Voluntary_4_Process & Send _Event_INFO
UK_Voluntary_5_Receive & Analyze_Question_CS
UK_Voluntary_6_Send Reply_Question_CS
UK_Voluntary_7_Forward_Question_CS
UK_Voluntary_8_Receive, Analyze & Send_Question_INFO
UK_Voluntary_9_Forward_Answer_CS
UK_Voluntary_10_Process & Send _Instruction_INST
UK_Voluntary_11_Forward_Instruction_INST
UK_Voluntary_12_Process & Send (All)_Reconciliation_PAY
UK_Voluntary_13_Receive, Analyze & Send_Problem_REC
UK_Voluntary_14_Process & Send _Payment_PAY
UK_Voluntary_15_Forward_Info Payments_PAY
UK_Voluntary_16_Send Reply_Info Payments_CS
UK_Voluntary_17_Process & Send (All)_Cleaning_PAY
UK_Voluntary_18_Receive, Analyze & Send_Problem_REC
UK_Voluntary_19_Receive, Analyze & Send_Problem_NI
EN_Voluntary_1_Receive, Analyze & Send_Info_INFO
EN_Voluntary_2_Request_Code Creation_INFO
EN_Voluntary_3_Create_Code_NI
EN_Voluntary_4_Process & Send _Event_INFO
EN_Voluntary_5_Receive & Analyze_Question_CS
EN_Voluntary_6_Send Reply_Question_CS
EN_Voluntary_7_Forward_Question_CS
EN_Voluntary_8_Receive, Analyze & Send_Question_INFO
EN_Voluntary_9_Forward_Answer_CS
EN_Voluntary_10_Process & Send _Instruction_INST
EN_Voluntary_11_Forward_Instruction_INST
EN_Voluntary_12_Process & Send (All)_Reconciliation_PAY
EN_Voluntary_13_Receive, Analyze & Send_Problem_REC
EN_Voluntary_14_Process & Send _Payment_PAY
EN_Voluntary_15_Forward_Info Payments_PAY
EN_Voluntary_16_Send Reply_Info Payments_CS
EN_Voluntary_17_Process & Send (All)_Cleaning_PAY
EN_Voluntary_18_Receive, Analyze & Send_Problem_REC
EN_Voluntary_19_Receive, Analyze & Send_Problem_NI
DR_Meetings_2_Request_Info Clarification_INFO
Ch a pt er 5: Methodology followed and Case Study
0.3 0.7
1
0.1
0.9
0.4 0.6
1
1
0.2
0.8
1
0.3
0.1
0.7
0.1
0.1
1
1
1
0.3 0.7
SERVICE 1
1
0.1
0.9
0.4 0.6
1
1
0.2
0.8
1
0.3
0.1
0.7
0.1
0.1
1
1
1
0.3 0.7
1
0.1
0.9
0.4 0.6
1
1
0.2
0.8
1
0.3
0.1
0.7
0.1
0.1
1
1
1
0.5
1
1
1
0.2
0.9
0.4 0.6
1
1
0.2
0.8
1
0.3 0.2
0.7 0.7
1
1
0.2
SERVICE 2
0.3 0.7
0.5
1
1
1
0.2
0.9
0.4 0.6
1
1
0.2
0.8
1
0.3 0.2
0.7 0.7
1
1
1
0.2
1
0.3 0.7
0.5
1
1
1
0.2
0.9
0.4 0.6
1
1
0.2
0.8
1
0.3 0.2
0.7 0.7
1
1
0.2
0.5
1
1
1
0.2
0.2
0.7
0.4 0.6
1
1
0.2
0.8
1
1
1
0.3 0.3
0.7 0.7
1
1
0.2
0.3 0.7
SERVICE 3
0.5
1
1
1
0.2
0.2
0.7
0.4 0.6
1
1
0.2
0.8
1
1
1
0.3 0.3
0.7 0.7
1
1
1
0.2
1
0.3 0.7
0.5
1
1
1
0.2
0.2
0.7
0.4 0.6
1
1
0.2
0.8
1
1
1
0.3 0.3
0.7 0.7
1
1
0.2
Figure 5.6: Process-Matrix: Process flow based on swim-lanes
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
0.3 0.7
Page 47
0.3 0.7
Ch a pt er 5: Methodology followed and Case Study
Figure 5.7: Part of Process-Matrix (Figure 5.6)
Figure 5.7 represents a part of the 150 x 150 Process Matrix for Service 1. Each
dependency above the matrix diagonal implies a feed-forward, while each
dependency below the diagonal a feedback than can lead to unintentional iteration and
rework.
The final step at this stage was to represent the dependencies of the Jobs with the
other domains, i.e. Markets, Services, Functions, using the respective DMMs (Figure
5.8).
Consequently, the acquired direct system dependencies will be used in the next
Section to derive indirect dependency networks between the jobs.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 48
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Market A_Service 1_1_Receive & Analyze_Info_INFO
Market A_Service 1_2_Request_Info Clarification_INFO
Market A_Service 1_3_Process & Send _Event_INFO
Market A_Service 1_4_Receive & Analyze_Question_CS
Market A_Service 1_5_Send Reply_Question_CS
Market A_Service 1_6_Forward_Question_CS
Market A_Service 1_7_Receive, Analyze & Send_Question_INFO
Market A_Service 1_8_Forward_Answer_CS
Market A_Service 1_9_Receive & Analyze_Instruction_INST
Market A_Service 1_10_Forward_Instruction_INST
Market A_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market A_Service 1_12_Forward_Instruction_CS
Market A_Service 1_13_Request_Instruction Documentation_CS
Market A_Service 1_14_Process & Send _Instruction_INST
Market A_Service 2_1_Receive & Analyze_Info_INFO
Market A_Service 2_2_Request_Code Creation_INFO
Market A_Service 2_3_Create_Code_AU
Market A_Service 2_4_Process & Send _Event_INFO
Market A_Service 2_5_Receive & Analyze_Question_CS
Market A_Service 2_6_Send Reply_Question_CS
Market A_Service 2_7_Forward_Question_CS
Market A_Service 2_8_Receive, Analyze & Send_Question_INFO
Market A_Service 2_9_Forward_Answer_CS
Market A_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market A_Service 2_11_Receive, Analyze & Send_Problem_REC
Market A_Service 2_12_Process & Send _Payment_PAY
Market A_Service 2_13_Forward_Info Payments_PAY
Market A_Service 2_14_Send Reply_Info Payments_CS
Market A_Service 2_15_Process & Send (All)_Cleaning_PAY
Market A_Service 2_16_Receive, Analyze & Send_Problem_REC
Market A_Service 2_17_Receive, Analyze & Send_Problem_AU
Market A_Service 3_1_Receive, Analyze & Send_Info_INFO
Market A_Service 3_2_Request_Code Creation_INFO
Market A_Service 3_3_Create_Code_AU
Market A_Service 3_4_Process & Send _Event_INFO
Market A_Service 3_5_Receive & Analyze_Question_CS
Market A_Service 3_6_Send Reply_Question_CS
Market A_Service 3_7_Forward_Question_CS
Market A_Service 3_8_Receive, Analyze & Send_Question_INFO
Market A_Service 3_9_Forward_Answer_CS
Market A_Service 3_10_Process & Send _Instruction_INST
Market A_Service 3_11_Forward_Instruction_INST
Market A_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market A_Service 3_13_Receive, Analyze & Send_Problem_REC
Market A_Service 3_14_Process & Send _Payment_PAY
Market A_Service 3_15_Forward_Info Payments_PAY
Market A_Service 3_16_Send Reply_Info Payments_CS
Market A_Service 3_17_Process & Send (All)_Cleaning_PAY
Market A_Service 3_18_Receive, Analyze & Send_Problem_REC
Market A_Service 3_19_Receive, Analyze & Send_Problem_AU
Market B_Service 1_1_Receive & Analyze_Info_INFO
Market B_Service 1_2_Request_Info Clarification_INFO
Market B_Service 1_3_Process & Send _Event_INFO
Market B_Service 1_4_Receive & Analyze_Question_CS
Market B_Service 1_5_Send Reply_Question_CS
Market B_Service 1_6_Forward_Question_CS
Market B_Service 1_7_Receive, Analyze & Send_Question_INFO
Market B_Service 1_8_Forward_Answer_CS
Market B_Service 1_9_Receive & Analyze_Instruction_INST
Market B_Service 1_10_Forward_Instruction_INST
Market B_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market B_Service 1_12_Forward_Instruction_CS
Market B_Service 1_13_Request_Instruction Documentation_CS
Market B_Service 1_14_Process & Send _Instruction_INST
Market B_Service 2_1_Receive & Analyze_Info_INFO
Market B_Service 2_2_Request_Code Creation_INFO
Market B_Service 2_3_Create_Code_AU
Market B_Service 2_4_Process & Send _Event_INFO
Market B_Service 2_5_Receive & Analyze_Question_CS
Market B_Service 2_6_Send Reply_Question_CS
Market B_Service 2_7_Forward_Question_CS
Market B_Service 2_8_Receive, Analyze & Send_Question_INFO
Market B_Service 2_9_Forward_Answer_CS
Market B_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market B_Service 2_11_Receive, Analyze & Send_Problem_REC
Market B_Service 2_12_Process & Send _Payment_PAY
Market B_Service 2_13_Forward_Info Payments_PAY
Market B_Service 2_14_Send Reply_Info Payments_CS
Market B_Service 2_15_Process & Send (All)_Cleaning_PAY
Market B_Service 2_16_Receive, Analyze & Send_Problem_REC
Market B_Service 2_17_Receive, Analyze & Send_Problem_AU
Market B_Service 3_1_Receive, Analyze & Send_Info_INFO
Market B_Service 3_2_Request_Code Creation_INFO
Market B_Service 3_3_Create_Code_AU
Market B_Service 3_4_Process & Send _Event_INFO
Market B_Service 3_5_Receive & Analyze_Question_CS
Market B_Service 3_6_Send Reply_Question_CS
Market B_Service 3_7_Forward_Question_CS
Market B_Service 3_8_Receive, Analyze & Send_Question_INFO
Market B_Service 3_9_Forward_Answer_CS
Market B_Service 3_10_Process & Send _Instruction_INST
Market B_Service 3_11_Forward_Instruction_INST
Market B_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market B_Service 3_13_Receive, Analyze & Send_Problem_REC
Market B_Service 3_14_Process & Send _Payment_PAY
Market B_Service 3_15_Forward_Info Payments_PAY
Market B_Service 3_16_Send Reply_Info Payments_CS
Market B_Service 3_17_Process & Send (All)_Cleaning_PAY
Market B_Service 3_18_Receive, Analyze & Send_Problem_REC
Market B_Service 3_19_Receive, Analyze & Send_Problem_AU
Market C_Service 1_1_Receive & Analyze_Info_INFO
Market C_Service 1_2_Request_Info Clarification_INFO
Market C_Service 1_3_Process & Send _Event_INFO
Market C_Service 1_4_Receive & Analyze_Question_CS
Market C_Service 1_5_Send Reply_Question_CS
Market C_Service 1_6_Forward_Question_CS
Market C_Service 1_7_Receive, Analyze & Send_Question_INFO
Market C_Service 1_8_Forward_Answer_CS
Market C_Service 1_9_Receive & Analyze_Instruction_INST
Market C_Service 1_10_Forward_Instruction_INST
Market C_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market C_Service 1_12_Forward_Instruction_CS
Market C_Service 1_13_Request_Instruction Documentation_CS
Market C_Service 1_14_Process & Send _Instruction_INST
Market C_Service 2_1_Receive & Analyze_Info_INFO
Market C_Service 2_2_Request_Code Creation_INFO
Market C_Service 2_3_Create_Code_AU
Market C_Service 2_4_Process & Send _Event_INFO
Market C_Service 2_5_Receive & Analyze_Question_CS
Market C_Service 2_6_Send Reply_Question_CS
Market C_Service 2_7_Forward_Question_CS
Market C_Service 2_8_Receive, Analyze & Send_Question_INFO
Market C_Service 2_9_Forward_Answer_CS
Market C_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market C_Service 2_11_Receive, Analyze & Send_Problem_REC
Market C_Service 2_12_Process & Send _Payment_PAY
Market C_Service 2_13_Forward_Info Payments_PAY
Market C_Service 2_14_Send Reply_Info Payments_CS
Market C_Service 2_15_Process & Send (All)_Cleaning_PAY
Market C_Service 2_16_Receive, Analyze & Send_Problem_REC
Market C_Service 2_17_Receive, Analyze & Send_Problem_AU
Market C_Service 3_1_Receive, Analyze & Send_Info_INFO
Market C_Service 3_2_Request_Code Creation_INFO
Market C_Service 3_3_Create_Code_AU
Market C_Service 3_4_Process & Send _Event_INFO
Market C_Service 3_5_Receive & Analyze_Question_CS
Market C_Service 3_6_Send Reply_Question_CS
Market C_Service 3_7_Forward_Question_CS
Market C_Service 3_8_Receive, Analyze & Send_Question_INFO
Market C_Service 3_9_Forward_Answer_CS
Market C_Service 3_10_Process & Send _Instruction_INST
Market C_Service 3_11_Forward_Instruction_INST
Market C_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market C_Service 3_13_Receive, Analyze & Send_Problem_REC
Market C_Service 3_14_Process & Send _Payment_PAY
Market C_Service 3_15_Forward_Info Payments_PAY
Market C_Service 3_16_Send Reply_Info Payments_CS
Market C_Service 3_17_Process & Send (All)_Cleaning_PAY
Market C_Service 3_18_Receive, Analyze & Send_Problem_REC
Market C_Service 3_19_Receive, Analyze & Send_Problem_AU
MARKET C
MARKET B
SERVICE 3
1
1
1
1
1
1
1
1
1
1
1
1
1
1
MARKET A
Market A_Service 1_1_Receive & Analyze_Info_INFO
Market A_Service 1_2_Request_Info Clarification_INFO
Market A_Service 1_3_Process & Send _Event_INFO
Market A_Service 1_4_Receive & Analyze_Question_CS
Market A_Service 1_5_Send Reply_Question_CS
Market A_Service 1_6_Forward_Question_CS
Market A_Service 1_7_Receive, Analyze & Send_Question_INFO
Market A_Service 1_8_Forward_Answer_CS
Market A_Service 1_9_Receive & Analyze_Instruction_INST
Market A_Service 1_10_Forward_Instruction_INST
Market A_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market A_Service 1_12_Forward_Instruction_CS
Market A_Service 1_13_Request_Instruction Documentation_CS
Market A_Service 1_14_Process & Send _Instruction_INST
Market A_Service 2_1_Receive & Analyze_Info_INFO
Market A_Service 2_2_Request_Code Creation_INFO
Market A_Service 2_3_Create_Code_AU
Market A_Service 2_4_Process & Send _Event_INFO
Market A_Service 2_5_Receive & Analyze_Question_CS
Market A_Service 2_6_Send Reply_Question_CS
Market A_Service 2_7_Forward_Question_CS
Market A_Service 2_8_Receive, Analyze & Send_Question_INFO
Market A_Service 2_9_Forward_Answer_CS
Market A_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market A_Service 2_11_Receive, Analyze & Send_Problem_REC
Market A_Service 2_12_Process & Send _Payment_PAY
Market A_Service 2_13_Forward_Info Payments_PAY
Market A_Service 2_14_Send Reply_Info Payments_CS
Market A_Service 2_15_Process & Send (All)_Cleaning_PAY
Market A_Service 2_16_Receive, Analyze & Send_Problem_REC
Market A_Service 2_17_Receive, Analyze & Send_Problem_AU
Market A_Service 3_1_Receive, Analyze & Send_Info_INFO
Market A_Service 3_2_Request_Code Creation_INFO
Market A_Service 3_3_Create_Code_AU
Market A_Service 3_4_Process & Send _Event_INFO
Market A_Service 3_5_Receive & Analyze_Question_CS
Market A_Service 3_6_Send Reply_Question_CS
Market A_Service 3_7_Forward_Question_CS
Market A_Service 3_8_Receive, Analyze & Send_Question_INFO
Market A_Service 3_9_Forward_Answer_CS
Market A_Service 3_10_Process & Send _Instruction_INST
Market A_Service 3_11_Forward_Instruction_INST
Market A_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market A_Service 3_13_Receive, Analyze & Send_Problem_REC
Market A_Service 3_14_Process & Send _Payment_PAY
Market A_Service 3_15_Forward_Info Payments_PAY
Market A_Service 3_16_Send Reply_Info Payments_CS
Market A_Service 3_17_Process & Send (All)_Cleaning_PAY
Market A_Service 3_18_Receive, Analyze & Send_Problem_REC
Market A_Service 3_19_Receive, Analyze & Send_Problem_AU
Market B_Service 1_1_Receive & Analyze_Info_INFO
Market B_Service 1_2_Request_Info Clarification_INFO
Market B_Service 1_3_Process & Send _Event_INFO
Market B_Service 1_4_Receive & Analyze_Question_CS
Market B_Service 1_5_Send Reply_Question_CS
Market B_Service 1_6_Forward_Question_CS
Market B_Service 1_7_Receive, Analyze & Send_Question_INFO
Market B_Service 1_8_Forward_Answer_CS
Market B_Service 1_9_Receive & Analyze_Instruction_INST
Market B_Service 1_10_Forward_Instruction_INST
Market B_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market B_Service 1_12_Forward_Instruction_CS
Market B_Service 1_13_Request_Instruction Documentation_CS
Market B_Service 1_14_Process & Send _Instruction_INST
Market B_Service 2_1_Receive & Analyze_Info_INFO
Market B_Service 2_2_Request_Code Creation_INFO
Market B_Service 2_3_Create_Code_AU
Market B_Service 2_4_Process & Send _Event_INFO
Market B_Service 2_5_Receive & Analyze_Question_CS
Market B_Service 2_6_Send Reply_Question_CS
Market B_Service 2_7_Forward_Question_CS
Market B_Service 2_8_Receive, Analyze & Send_Question_INFO
Market B_Service 2_9_Forward_Answer_CS
Market B_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market B_Service 2_11_Receive, Analyze & Send_Problem_REC
Market B_Service 2_12_Process & Send _Payment_PAY
Market B_Service 2_13_Forward_Info Payments_PAY
Market B_Service 2_14_Send Reply_Info Payments_CS
Market B_Service 2_15_Process & Send (All)_Cleaning_PAY
Market B_Service 2_16_Receive, Analyze & Send_Problem_REC
Market B_Service 2_17_Receive, Analyze & Send_Problem_AU
Market B_Service 3_1_Receive, Analyze & Send_Info_INFO
Market B_Service 3_2_Request_Code Creation_INFO
Market B_Service 3_3_Create_Code_AU
Market B_Service 3_4_Process & Send _Event_INFO
Market B_Service 3_5_Receive & Analyze_Question_CS
Market B_Service 3_6_Send Reply_Question_CS
Market B_Service 3_7_Forward_Question_CS
Market B_Service 3_8_Receive, Analyze & Send_Question_INFO
Market B_Service 3_9_Forward_Answer_CS
Market B_Service 3_10_Process & Send _Instruction_INST
Market B_Service 3_11_Forward_Instruction_INST
Market B_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market B_Service 3_13_Receive, Analyze & Send_Problem_REC
Market B_Service 3_14_Process & Send _Payment_PAY
Market B_Service 3_15_Forward_Info Payments_PAY
Market B_Service 3_16_Send Reply_Info Payments_CS
Market B_Service 3_17_Process & Send (All)_Cleaning_PAY
Market B_Service 3_18_Receive, Analyze & Send_Problem_REC
Market B_Service 3_19_Receive, Analyze & Send_Problem_AU
Market C_Service 1_1_Receive & Analyze_Info_INFO
Market C_Service 1_2_Request_Info Clarification_INFO
Market C_Service 1_3_Process & Send _Event_INFO
Market C_Service 1_4_Receive & Analyze_Question_CS
Market C_Service 1_5_Send Reply_Question_CS
Market C_Service 1_6_Forward_Question_CS
Market C_Service 1_7_Receive, Analyze & Send_Question_INFO
Market C_Service 1_8_Forward_Answer_CS
Market C_Service 1_9_Receive & Analyze_Instruction_INST
Market C_Service 1_10_Forward_Instruction_INST
Market C_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market C_Service 1_12_Forward_Instruction_CS
Market C_Service 1_13_Request_Instruction Documentation_CS
Market C_Service 1_14_Process & Send _Instruction_INST
Market C_Service 2_1_Receive & Analyze_Info_INFO
Market C_Service 2_2_Request_Code Creation_INFO
Market C_Service 2_3_Create_Code_AU
Market C_Service 2_4_Process & Send _Event_INFO
Market C_Service 2_5_Receive & Analyze_Question_CS
Market C_Service 2_6_Send Reply_Question_CS
Market C_Service 2_7_Forward_Question_CS
Market C_Service 2_8_Receive, Analyze & Send_Question_INFO
Market C_Service 2_9_Forward_Answer_CS
Market C_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market C_Service 2_11_Receive, Analyze & Send_Problem_REC
Market C_Service 2_12_Process & Send _Payment_PAY
Market C_Service 2_13_Forward_Info Payments_PAY
Market C_Service 2_14_Send Reply_Info Payments_CS
Market C_Service 2_15_Process & Send (All)_Cleaning_PAY
Market C_Service 2_16_Receive, Analyze & Send_Problem_REC
Market C_Service 2_17_Receive, Analyze & Send_Problem_AU
Market C_Service 3_1_Receive, Analyze & Send_Info_INFO
Market C_Service 3_2_Request_Code Creation_INFO
Market C_Service 3_3_Create_Code_AU
Market C_Service 3_4_Process & Send _Event_INFO
Market C_Service 3_5_Receive & Analyze_Question_CS
Market C_Service 3_6_Send Reply_Question_CS
Market C_Service 3_7_Forward_Question_CS
Market C_Service 3_8_Receive, Analyze & Send_Question_INFO
Market C_Service 3_9_Forward_Answer_CS
Market C_Service 3_10_Process & Send _Instruction_INST
Market C_Service 3_11_Forward_Instruction_INST
Market C_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market C_Service 3_13_Receive, Analyze & Send_Problem_REC
Market C_Service 3_14_Process & Send _Payment_PAY
Market C_Service 3_15_Forward_Info Payments_PAY
Market C_Service 3_16_Send Reply_Info Payments_CS
Market C_Service 3_17_Process & Send (All)_Cleaning_PAY
Market C_Service 3_18_Receive, Analyze & Send_Problem_REC
Market C_Service 3_19_Receive, Analyze & Send_Problem_AU
SERVICE 2
SERVICE 1
Ch a pt er 5: Methodology followed and Case Study
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Page 49
AU
REC
PAY
INST
CS
Market A_Service 1_1_Receive & Analyze_Info_INFO
Market A_Service 1_2_Request_Info Clarification_INFO
Market A_Service 1_3_Process & Send _Event_INFO
Market A_Service 1_4_Receive & Analyze_Question_CS
Market A_Service 1_5_Send Reply_Question_CS
Market A_Service 1_6_Forward_Question_CS
Market A_Service 1_7_Receive, Analyze & Send_Question_INFO
Market A_Service 1_8_Forward_Answer_CS
Market A_Service 1_9_Receive & Analyze_Instruction_INST
Market A_Service 1_10_Forward_Instruction_INST
Market A_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market A_Service 1_12_Forward_Instruction_CS
Market A_Service 1_13_Request_Instruction Documentation_CS
Market A_Service 1_14_Process & Send _Instruction_INST
Market A_Service 2_1_Receive & Analyze_Info_INFO
Market A_Service 2_2_Request_Code Creation_INFO
Market A_Service 2_3_Create_Code_AU
Market A_Service 2_4_Process & Send _Event_INFO
Market A_Service 2_5_Receive & Analyze_Question_CS
Market A_Service 2_6_Send Reply_Question_CS
Market A_Service 2_7_Forward_Question_CS
Market A_Service 2_8_Receive, Analyze & Send_Question_INFO
Market A_Service 2_9_Forward_Answer_CS
Market A_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market A_Service 2_11_Receive, Analyze & Send_Problem_REC
Market A_Service 2_12_Process & Send _Payment_PAY
Market A_Service 2_13_Forward_Info Payments_PAY
Market A_Service 2_14_Send Reply_Info Payments_CS
Market A_Service 2_15_Process & Send (All)_Cleaning_PAY
Market A_Service 2_16_Receive, Analyze & Send_Problem_REC
Market A_Service 2_17_Receive, Analyze & Send_Problem_AU
Market A_Service 3_1_Receive, Analyze & Send_Info_INFO
Market A_Service 3_2_Request_Code Creation_INFO
Market A_Service 3_3_Create_Code_AU
Market A_Service 3_4_Process & Send _Event_INFO
Market A_Service 3_5_Receive & Analyze_Question_CS
Market A_Service 3_6_Send Reply_Question_CS
Market A_Service 3_7_Forward_Question_CS
Market A_Service 3_8_Receive, Analyze & Send_Question_INFO
Market A_Service 3_9_Forward_Answer_CS
Market A_Service 3_10_Process & Send _Instruction_INST
Market A_Service 3_11_Forward_Instruction_INST
Market A_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market A_Service 3_13_Receive, Analyze & Send_Problem_REC
Market A_Service 3_14_Process & Send _Payment_PAY
Market A_Service 3_15_Forward_Info Payments_PAY
Market A_Service 3_16_Send Reply_Info Payments_CS
Market A_Service 3_17_Process & Send (All)_Cleaning_PAY
Market A_Service 3_18_Receive, Analyze & Send_Problem_REC
Market A_Service 3_19_Receive, Analyze & Send_Problem_AU
Market B_Service 1_1_Receive & Analyze_Info_INFO
Market B_Service 1_2_Request_Info Clarification_INFO
Market B_Service 1_3_Process & Send _Event_INFO
Market B_Service 1_4_Receive & Analyze_Question_CS
Market B_Service 1_5_Send Reply_Question_CS
Market B_Service 1_6_Forward_Question_CS
Market B_Service 1_7_Receive, Analyze & Send_Question_INFO
Market B_Service 1_8_Forward_Answer_CS
Market B_Service 1_9_Receive & Analyze_Instruction_INST
Market B_Service 1_10_Forward_Instruction_INST
Market B_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market B_Service 1_12_Forward_Instruction_CS
Market B_Service 1_13_Request_Instruction Documentation_CS
Market B_Service 1_14_Process & Send _Instruction_INST
Market B_Service 2_1_Receive & Analyze_Info_INFO
Market B_Service 2_2_Request_Code Creation_INFO
Market B_Service 2_3_Create_Code_AU
Market B_Service 2_4_Process & Send _Event_INFO
Market B_Service 2_5_Receive & Analyze_Question_CS
Market B_Service 2_6_Send Reply_Question_CS
Market B_Service 2_7_Forward_Question_CS
Market B_Service 2_8_Receive, Analyze & Send_Question_INFO
Market B_Service 2_9_Forward_Answer_CS
Market B_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market B_Service 2_11_Receive, Analyze & Send_Problem_REC
Market B_Service 2_12_Process & Send _Payment_PAY
Market B_Service 2_13_Forward_Info Payments_PAY
Market B_Service 2_14_Send Reply_Info Payments_CS
Market B_Service 2_15_Process & Send (All)_Cleaning_PAY
Market B_Service 2_16_Receive, Analyze & Send_Problem_REC
Market B_Service 2_17_Receive, Analyze & Send_Problem_AU
Market B_Service 3_1_Receive, Analyze & Send_Info_INFO
Market B_Service 3_2_Request_Code Creation_INFO
Market B_Service 3_3_Create_Code_AU
Market B_Service 3_4_Process & Send _Event_INFO
Market B_Service 3_5_Receive & Analyze_Question_CS
Market B_Service 3_6_Send Reply_Question_CS
Market B_Service 3_7_Forward_Question_CS
Market B_Service 3_8_Receive, Analyze & Send_Question_INFO
Market B_Service 3_9_Forward_Answer_CS
Market B_Service 3_10_Process & Send _Instruction_INST
Market B_Service 3_11_Forward_Instruction_INST
Market B_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market B_Service 3_13_Receive, Analyze & Send_Problem_REC
Market B_Service 3_14_Process & Send _Payment_PAY
Market B_Service 3_15_Forward_Info Payments_PAY
Market B_Service 3_16_Send Reply_Info Payments_CS
Market B_Service 3_17_Process & Send (All)_Cleaning_PAY
Market B_Service 3_18_Receive, Analyze & Send_Problem_REC
Market B_Service 3_19_Receive, Analyze & Send_Problem_AU
Market C_Service 1_1_Receive & Analyze_Info_INFO
Market C_Service 1_2_Request_Info Clarification_INFO
Market C_Service 1_3_Process & Send _Event_INFO
Market C_Service 1_4_Receive & Analyze_Question_CS
Market C_Service 1_5_Send Reply_Question_CS
Market C_Service 1_6_Forward_Question_CS
Market C_Service 1_7_Receive, Analyze & Send_Question_INFO
Market C_Service 1_8_Forward_Answer_CS
Market C_Service 1_9_Receive & Analyze_Instruction_INST
Market C_Service 1_10_Forward_Instruction_INST
Market C_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market C_Service 1_12_Forward_Instruction_CS
Market C_Service 1_13_Request_Instruction Documentation_CS
Market C_Service 1_14_Process & Send _Instruction_INST
Market C_Service 2_1_Receive & Analyze_Info_INFO
Market C_Service 2_2_Request_Code Creation_INFO
Market C_Service 2_3_Create_Code_AU
Market C_Service 2_4_Process & Send _Event_INFO
Market C_Service 2_5_Receive & Analyze_Question_CS
Market C_Service 2_6_Send Reply_Question_CS
Market C_Service 2_7_Forward_Question_CS
Market C_Service 2_8_Receive, Analyze & Send_Question_INFO
Market C_Service 2_9_Forward_Answer_CS
Market C_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market C_Service 2_11_Receive, Analyze & Send_Problem_REC
Market C_Service 2_12_Process & Send _Payment_PAY
Market C_Service 2_13_Forward_Info Payments_PAY
Market C_Service 2_14_Send Reply_Info Payments_CS
Market C_Service 2_15_Process & Send (All)_Cleaning_PAY
Market C_Service 2_16_Receive, Analyze & Send_Problem_REC
Market C_Service 2_17_Receive, Analyze & Send_Problem_AU
Market C_Service 3_1_Receive, Analyze & Send_Info_INFO
Market C_Service 3_2_Request_Code Creation_INFO
Market C_Service 3_3_Create_Code_AU
Market C_Service 3_4_Process & Send _Event_INFO
Market C_Service 3_5_Receive & Analyze_Question_CS
Market C_Service 3_6_Send Reply_Question_CS
Market C_Service 3_7_Forward_Question_CS
Market C_Service 3_8_Receive, Analyze & Send_Question_INFO
Market C_Service 3_9_Forward_Answer_CS
Market C_Service 3_10_Process & Send _Instruction_INST
Market C_Service 3_11_Forward_Instruction_INST
Market C_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market C_Service 3_13_Receive, Analyze & Send_Problem_REC
Market C_Service 3_14_Process & Send _Payment_PAY
Market C_Service 3_15_Forward_Info Payments_PAY
Market C_Service 3_16_Send Reply_Info Payments_CS
Market C_Service 3_17_Process & Send (All)_Cleaning_PAY
Market C_Service 3_18_Receive, Analyze & Send_Problem_REC
Market C_Service 3_19_Receive, Analyze & Send_Problem_AU
INFO
Ch a pt er 5: Methodology followed and Case Study
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Figure 5.8: DMMs connecting Jobs with Services, Markets and Functions
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 50
Ch a pt er 5: Methodology followed and Case Study
5.3.3. Deduction of Indirect Dependencies
After the definition of the system and the systematic acquisition of all the required
direct dependencies at intra-domain and inter-domain level, all the initially selected
domains of the MDM are filled with data. We can now focus our analysis on mapping
the indirect dependencies between system’s jobs. For example two jobs could share a
dependency because they are parts of the same service. Such a dependency is indirect
and needs to be computed, as it cannot be easily identified during information
acquisition. This can be accomplished using the inter-domain dependencies stored in
the DMM. Using the approach of Appendix C, we can now transform the acquired
data into DSMs (i.e. filled solely with Job-Job dependencies) by multiplying each
DMM with its transpose. Hence, we can document how Jobs are connected due to
interdependencies related to Market, Service or Function.
Figure 5.9 to
Figure 5.12
describe the logic behind the computations and the derived
matrices.
Figure 5.9: “Job A and Job B are linked to each other when they both are part of the same
Market, Service or contribute to the same Function”
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 51
Ch a pt er 5: Methodology followed and Case Study
Figure 5.10: Computed Job dependencies via Markets
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 52
Ch a pt er 5: Methodology followed and Case Study
Figure 5.11: Computed Job dependencies via Services
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 53
Ch a pt er 5: Methodology followed and Case Study
Figure 5.12: Computed Job dependencies via Functions
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 54
Ch a pt er 5: Methodology followed and Case Study
5.3.4. Structure Analysis
The objective of structure analysis is to identify structural characteristics of the
system in question that would help us assess the organization’s structure based on the
three assigned scenarios. The following procedure was followed using the computed
matrices from the previous steps.
We started by combining the derived structural views into a new “Aggregated” matrix
(see Figure 5.13) that would involve job dependencies across all system domains.
This practically means adding Figure 5.6,
Figure 5.10, Figure 5.11
and
Figure 5.12.
This is
consistent with Lindemann et al. who note that structures should be evaluated based
on several views of the system and not only with regard to a single dependency type
such as, for example, information dependencies (see Figure 5.6). Therefore, in order
for the whole system to be taken into account different structural views need to be
placed over each other.
Following that, our goal was to model each structure from the available scenarios of
Figure 5.4. That was accomplished by manually rearranging the rows and columns of
the Aggregated matrix in order to create targeted views for each structure
independently. Thus, for the 1 st scenario we needed to create a DSM that resembles
the functional structure of the organization’s current structure. By rearranging the
rows and columns of the aggregated matrix we can sort system jobs based on function
similarity. The boxes around the diagonal indicate the six functional departments of
the organization’s current structure. Scores inside the boxes indicate interfaces
between jobs of the same department. Scores outside the boxes indicate interfaces
between jobs of different departments (see Figure 5.14). Maintaining the same logic we
continued modeling the remaining two scenarios. Thus, once more, by rearranging the
rows and columns of the Aggregated matrix we generated three clusters that enclose
jobs that belong to the same service (see Figure 5.15) for scenario 2 and three with jobs
that are available to the same market (see Figure 5.16) for scenario 3.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 55
Ch a pt er 5: Methodology followed and Case Study
Figure 5.13: Modeling the Aggregated view
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 56
Ch a pt er 5: Methodology followed and Case Study
Figure 5.14: Weighted matrix with varying interactions. Scenario 1: Organization by Function
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 57
Ch a pt er 5: Methodology followed and Case Study
Figure 5.15: Weighted matrix with varying dependencies. Scenario 2: Organization by Service
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 58
Ch a pt er 5: Methodology followed and Case Study
Figure 5.16: Weighted matrix with varying interactions. Scenario 3: Organization by Market ( also Modular scenario)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 59
Ch a pt er 5: Methodology followed and Case Study
After we had modeled all three scenarios we decided to broaden the scope of our
analysis. Specifically, we wanted to address questions such as “what is the best
solution to our problem?” or “given that no structural scenarios were available, how
would we choose to organize jobs?”
With these queries in mind we proceeded introducing an additional structure scenario.
For this scenario we would carry out a clustering analysis on the Aggregated matrix of
Figure 5.13 using the clustering algorithm of Thebeau (2001). We expected the
algorithm to identify structural subsets (here organizational departments) that their
amount of internal dependencies is greater compared to their number of external ones.
The identified clusters would provide the basis for creating modules (i.e. service
cells). Thus, a change to a job could cause impact within the members of its cell
without need for adaptation outside the boundaries of the module, making each cell
independent.
Interestingly enough the generated matrix turned out to be identical with that of
5.16.
Figure
This result could be an indication that indeed the best structure is that of scenario
3 (i.e. organization by market). In order to reinforce this judgment we continued with
the evaluation of each scenario across four structural metrics (for a detailed
description of these metrics refer to Appendix F) :
1. Number of clusters: The number of identified clusters within each structure.
The lower the value of number of clusters, the better the clustering is, that is,
two clusters are easier to manage than three.
2. Coverage: Quotient of interactions within clusters to the sum of system
interactions. The higher the value of coverage, the better the clustering is, that
is, it is more convenient to address job interactions within departments that
outside those.
3. Coordination Cost: The coordination cost of Jobs based on the algorithm of
Thebeau (2009). The lower the value of coordination cost, the better the
clustering. Coordination cost covers various aspects such as that is better to
address interactions within clusters than ignoring them or that each cost of
addressing an interaction is proportional to the frequency and importance of
the interaction (for more details refer to Fernandez, 1998)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 60
Ch a pt er 5: Methodology followed and Case Study
4. Measure of Effectiveness: The sum of products between each job and its
nearest-neighbor elements. The lower the value of measure of effectiveness the
better the clustering. Measure of effectiveness tests the level of density
between matrix elements in order to assess clustering quality.
Table 5.3 presents the obtained results after each structural metric was calculated.
From this assessment table, there are some interesting observations to be derived.
Firstly, we see that both scenarios 2 and 3 (i.e. organization by Service and Market
respectively) produced less clusters than the original structure (i.e. organization by
Function). Thus, the effectiveness of the system is vastly improved as job interactions
are addressed by three departments instead of six. Secondly, coverage values indicate
that an organization by Market addresses more dependencies within clusters
compared to the other structural scenarios. Moreover, the cost of coordination for
scenario 3 will be considerably lower as the formed clusters include the most
important and frequent interactions, ignoring only a few. Lastly, the low value for the
measure of effectiveness metric suggests that the clustering quality of scenario’s 3
matrix is better than the others. On the whole, the four structural metrics suggest that
the structure of scenario 3 (organization by Market) presents the most “modular
behavior” as each of the identified subsets depends less upon the others.
Table 5.3: Inter-cluster assessment table
Inter-cluster
Structural Views
Market
Function
Service
Modular
# of
Clusters
3
6
3
3
Assessment Metrics
Coordination
Coverage2
Cost3
0,657
424395
0,415
466963
0,559
599558
0,657
424395
Measure of
effectiveness2
9465
13653
13216
9465
Thus based on the results of the clustering algorithm and the above assessment we can
conclude that a structure organized by Market (Figure 5.17) reduces complexity to the
largest extent compared to the other alternatives. Moreover based on results of the
clustering analysis we argue that the structure of scenario 3 is indeed a modular
design. Each group of jobs within this arrangement constitutes a service cell. Each
cell involves several parts (jobs) that fulfill various functions required for the
2
Higher scores are better
Lower scores are better
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
3
Page 61
Ch a pt er 5: Methodology followed and Case Study
production of a specific family of products (Market A, B or C). Moreover, within
each “Market-cell” (i.e. cell that includes job of the same market) each service is
produced end-to-end permitting individual cells to operate independently from each
other
Figure 5.17: Best case scenario for inter-cluster analysis
5.3.5. Intra-cluster Structure Analysis
In many applications clusters may be too large to manage. In this case, it is necessary
to proceed further and analyze the intra-cluster structure. The challenge addressed in
this step, is to decide on how work is organized within each individual market cell.
What is the most effective way of grouping teams inside each department such that
complexity is reduced not only externally but also internally?
For the service organizational structure, each identified market cell constitutes a
separate structural platform containing platform elements and platform modules. As
Lindemann et al. (2009) note “a platform can be described as elements or subsystems
that together form a common basis from which individual products can be derived”.
Thus, modular sub-structures can be identified within each platform.
With that in mind and after discussing with the company’s management, we selected
two possible alternatives (scenarios 3a-3b) for organizing work inside each market
cell. For the assessment of the above scenarios the same steps of the approach were
followed in order to analyze modular sub-structures within each department.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 62
Ch a pt er 5: Methodology followed and Case Study
Figure 5.18: Scenarios 3a-3c for the assessment of platform's modular sub-structures
We will apply our approach only for the first identified Market cell of the system.
Once again, we followed the same steps as described in the structure analysis of the
previous Section. Each structural view was laid over each other in order to create an
aggregated view of the cell. However, this time in addition to the structural views of
process, function and service we also evaluated job dependencies taking into account
four attributes from the factors that influence service organizational structure and
were presented in Chapter 3.
Below we provide a description for each of the selected job attributes:
i.
Customer Contact
Definition: Extent to which contact with customer is required during the
execution of the job.
Outcomes: The value of this attribute range from 0 to 1 (not required,
required), and influence the decoupling decision between jobs and the
specification of workers skills (e.g. interpersonal skills for high-contact jobs).
ii.
Diagnosis
Definition: Extent to which diagnosis is required to perform the job
Outcomes: This attribute’s values range from 0 to 1 (not required, required).
The goal is to group diagnostic steps.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 63
Ch a pt er 5: Methodology followed and Case Study
iii.
Discretion
Definition: Extent to which worker should exercise personal judgment on the
completion of the job.
Outcomes: Discretionary jobs are more complex, and hence, need to be
decoupled. Thus, values range from 0 to -1 (non-discretionary, discretionary),
since coupling of jobs has a negative impact.
iv.
Risk
Definition: Perceived risk that an exchange has intrinsic risk to lead to loss
exposure.
Outcomes: Jobs involving risk should be decoupled for control and
counterchecking purposes. Attribute’s values range from 0 to -1 (not risk
Market C_Service 1_1_Receive & Analyze_Info_INFO
Market C_Service 1_2_Request_Info Clarification_INFO
Market C_Service 1_3_Process & Send _Event_INFO
Market C_Service 1_4_Receive & Analyze_Question_CS
Market C_Service 1_5_Send Reply_Question_CS
Market C_Service 1_6_Forward_Question_CS
Market C_Service 1_7_Receive, Analyze & Send_Question_INFO
Market C_Service 1_8_Forward_Answer_CS
Market C_Service 1_9_Receive & Analyze_Instruction_INST
Market C_Service 1_10_Forward_Instruction_INST
Market C_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market C_Service 1_12_Forward_Instruction_CS
Market C_Service 1_13_Request_Instruction Documentation_CS
Market C_Service 1_14_Process & Send _Instruction_INST
Market C_Service 2_1_Receive & Analyze_Info_INFO
Market C_Service 2_2_Request_Code Creation_INFO
Market C_Service 2_3_Create_Code_AU
Market C_Service 2_4_Process & Send _Event_INFO
Market C_Service 2_5_Receive & Analyze_Question_CS
Market C_Service 2_6_Send Reply_Question_CS
Market C_Service 2_7_Forward_Question_CS
Market C_Service 2_8_Receive, Analyze & Send_Question_INFO
Market C_Service 2_9_Forward_Answer_CS
Market C_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market C_Service 2_11_Receive, Analyze & Send_Problem_REC
Market C_Service 2_12_Process & Send _Payment_PAY
Market C_Service 2_13_Forward_Info Payments_PAY
Market C_Service 2_14_Send Reply_Info Payments_CS
Market C_Service 2_15_Process & Send (All)_Cleaning_PAY
Market C_Service 2_16_Receive, Analyze & Send_Problem_REC
Market C_Service 2_17_Receive, Analyze & Send_Problem_AU
Market C_Service 3_1_Receive, Analyze & Send_Info_INFO
Market C_Service 3_2_Request_Code Creation_INFO
Market C_Service 3_3_Create_Code_AU
Market C_Service 3_4_Process & Send _Event_INFO
Market C_Service 3_5_Receive & Analyze_Question_CS
Market C_Service 3_6_Send Reply_Question_CS
Market C_Service 3_7_Forward_Question_CS
Market C_Service 3_8_Receive, Analyze & Send_Question_INFO
Market C_Service 3_9_Forward_Answer_CS
Market C_Service 3_10_Process & Send _Instruction_INST
Market C_Service 3_11_Forward_Instruction_INST
Market C_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market C_Service 3_13_Receive, Analyze & Send_Problem_REC
Market C_Service 3_14_Process & Send _Payment_PAY
Market C_Service 3_15_Forward_Info Payments_PAY
Market C_Service 3_16_Send Reply_Info Payments_CS
Market C_Service 3_17_Process & Send (All)_Cleaning_PAY
Market C_Service 3_18_Receive, Analyze & Send_Problem_REC
Market C_Service 3_19_Receive, Analyze & Send_Problem_AU
1.0
2.0 1.0
1.0 1.0
-1.0
2.0 1.0
1.0
1.0 1.0 -1.0 1.0
-1.0
-1.0
1.0 2.0
-2.0 1.0 1.0
-2.0
1.0 1.0
2.0 1.0
1.0
1.0
-2.0
1.0
2.0
1.0 2.0
-2.0 1.0 1.0
-1.0
-1.0
-1.0
-1.0
1.0 1.0 1.0
2.0
-2.0 1.0 1.0 -1.0 1.0
-1.0
-2.0
-2.0
1.0 1.0
1.0
1.0
1.0
1.0 1.0
-1.0
-1.0
1.0
1.0
1.0 -1.0
-1.0 1.0
1.0
1.0
1.0
1.0
-1.0
1.0 1.0 1.0
1.0 1.0
-1.0
1.0
1.0
1.0
-1.0
1.0 1.0
-1.0
1.0
-1.0
1.0 1.0
-1.0
1.0
1.0
-1.0
-1.0
1.0
1.0
-2.0
-1.0
-1.0
-1.0
1.0
-1.0
-1.0
1.0
-1.0
1.0
1.0
1.0
-2.0
1.0 1.0
-1.0 -1.0
-1.0
1.0
-1.0 -1.0
-1.0
1.0 1.0
-1.0 -1.0
-1.0
1.0
1.0
1.0 -1.0
-1.0
-1.0 1.0 1.0
1.0
-1.0
1.0
-1.0
-1.0
-1.0
1.0
-1.0
-1.0
1.0
1.0
-2.0 1.0 -1.0
-1.0
-1.0
1.0 1.0 1.0
-1.0
-1.0
-1.0
-1.0
1.0
-1.0
-1.0
-1.0
1.0 1.0 1.0
-1.0
-1.0
-1.0
1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
1.0 1.0 1.0
2.0
-2.0 1.0 1.0 -1.0 1.0
-1.0 -1.0
-1.0 -1.0
-1.0
-1.0
2.0 1.0
-1.0 -1.0 1.0 -1.0
-1.0
-1.0
1.0 2.0
-2.0 1.0 1.0
-1.0
-2.0
-1.0 -1.0
-1.0
1.0
1.0
1.0
-1.0
1.0 1.0
1.0
1.0
1.0 1.0
-1.0
-1.0
-1.0
-1.0
1.0
1.0
-2.0 1.0 -1.0
-1.0
-1.0
-1.0
1.0
1.0 1.0 1.0
1.0 -1.0
-1.0
-2.0
-1.0
-1.0 -1.0 1.0
1.0
1.0
-1.0 -1.0
2.0
-2.0
-1.0
-1.0
2.0 1.0
-1.0 -1.0 1.0 -1.0
-1.0
-1.0
-1.0 -1.0
1.0 1.0
-1.0 -1.0
-1.0
1.0
1.0
1.0 -1.0
-1.0
-1.0
-1.0
1.0
-1.0
-1.0 -1.0 1.0
-1.0
-1.0
-1.0
1.0
-1.0
-1.0
1.0
-2.0 1.0 -1.0
-1.0
-1.0
-2.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0 -1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0 -1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
-1.0
1.0 1.0
1.0
1.0
1.0 1.0
-1.0
1.0
1.0
1.0
-1.0
-1.0 -1.0
1.0
1.0
1.0 1.0
-1.0
1.0
1.0
1.0
-1.0
-1.0
1.0
1.0
-1.0
-1.0 -1.0
1.0 1.0 1.0
1.0 1.0 1.0
Market C_Service 3_19_Receive, Analyze & Send_Problem_AU
-1.0
1.0
1.0 1.0
1.0 1.0
-1.0
1.0
1.0
-1.0
1.0
-1.0
-1.0
1.0
1.0
Figure 5.19: Computed job dependencies via attributes for the 1st identified cell
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
-1.0
-1.0
1.0
1.0 1.0
1.0 -1.0
1.0
-1.0 -1.0
1.0
-1.0
Market C_Service 3_17_Process & Send (All)_Cleaning_PAY
-1.0
-1.0
-1.0
Market C_Service 3_15_Forward_Info Payments_PAY
-1.0
-1.0
1.0 1.0
-1.0
1.0
1.0
-1.0
-1.0
1.0
-1.0
-1.0
1.0 1.0
1.0 1.0
1.0 1.0
-1.0
-2.0
1.0 1.0
-1.0
1.0 1.0
-1.0
-1.0
-1.0
-1.0 -1.0
1.0 1.0 1.0
-1.0
-1.0
-1.0
1.0
-2.0 1.0 -1.0
-1.0
1.0
1.0 1.0
-1.0
1.0
1.0
1.0
-1.0
-1.0
1.0
-1.0
1.0
-1.0
-1.0 -1.0
-1.0
-1.0
1.0
-1.0
1.0
1.0
1.0 1.0
1.0 -1.0
1.0
-1.0
-1.0
1.0 1.0
-1.0
-1.0
1.0
-1.0
1.0
-1.0
-1.0
1.0
-2.0
1.0
-1.0
1.0
-1.0
-1.0
-2.0
1.0 1.0
-1.0
-1.0
-1.0
1.0
-1.0 -1.0
1.0
1.0 1.0
-1.0 1.0 1.0
1.0
1.0
-1.0
1.0
Market C_Service 3_14_Process & Send _Payment_PAY
-1.0 1.0 -1.0
-1.0
1.0
-1.0
1.0
1.0
1.0
1.0
-1.0
1.0 1.0
-1.0
1.0
1.0 1.0
1.0 -1.0
-1.0
-1.0
-1.0
1.0
-1.0
1.0
-2.0
1.0 1.0
-1.0 -1.0
-1.0
1.0
1.0
-1.0
1.0
1.0
1.0
-2.0
1.0
1.0
-1.0
1.0
-2.0
1.0 1.0
-1.0 -1.0
-1.0
1.0
-1.0 -1.0
-1.0
1.0
Market C_Service 3_16_Send Reply_Info Payments_CS
Market C_Service 3_12_Process & Send (All)_Reconciliation_PAY
Market C_Service 3_11_Forward_Instruction_INST
-1.0 -1.0
Market C_Service 3_13_Receive, Analyze & Send_Problem_REC
Market C_Service 3_9_Forward_Answer_CS
Market C_Service 3_10_Process & Send _Instruction_INST
Market C_Service 3_7_Forward_Question_CS
Market C_Service 3_6_Send Reply_Question_CS
-1.0
-2.0
1.0 1.0
-1.0
1.0 1.0
-1.0
Market C_Service 3_8_Receive, Analyze & Send_Question_INFO
Market C_Service 3_2_Request_Code Creation_INFO
Market C_Service 3_3_Create_Code_AU
-1.0
1.0
-2.0 1.0 -1.0
-2.0
1.0 1.0
2.0 1.0
1.0
1.0
-1.0
1.0 1.0
-1.0
Market C_Service 3_5_Receive & Analyze_Question_CS
-1.0
-1.0 -1.0
-1.0 -1.0
1.0
1.0 1.0 1.0
1.0 -1.0
-1.0
-1.0
2.0 1.0
1.0 1.0
-1.0
2.0 1.0
-1.0 -1.0 1.0 -1.0
-1.0 -1.0
1.0 1.0 1.0
1.0
1.0
-1.0
Market C_Service 3_4_Process & Send _Event_INFO
Market C_Service 3_1_Receive, Analyze & Send_Info_INFO
Market C_Service 2_15_Process & Send (All)_Cleaning_PAY
Market C_Service 2_17_Receive, Analyze & Send_Problem_AU
Market C_Service 2_13_Forward_Info Payments_PAY
Market C_Service 2_12_Process & Send _Payment_PAY
Market C_Service 2_11_Receive, Analyze & Send_Problem_REC
Market C_Service 2_14_Send Reply_Info Payments_CS
-1.0
1.0
1.0
1.0
Market C_Service 2_16_Receive, Analyze & Send_Problem_REC
1.0 1.0 1.0
-1.0
1.0
1.0 1.0 1.0
1.0 -1.0
-1.0
-1.0
1.0
1.0
-1.0
-1.0
-1.0
1.0
1.0
-1.0 1.0 -1.0
-1.0
-1.0
-1.0
-1.0
-1.0
2.0 1.0
2.0 1.0
1.0 1.0 -1.0 1.0 -1.0
1.0
1.0
-1.0
1.0
1.0
-2.0
1.0
1.0
-1.0
1.0
-1.0 -1.0 1.0
1.0
-1.0
-1.0
1.0
1.0
-2.0 1.0 -1.0
-1.0
-1.0 -1.0 1.0
1.0
1.0
-1.0 -1.0
2.0
-1.0
Market C_Service 2_9_Forward_Answer_CS
1.0
1.0
-1.0 -1.0
-1.0
1.0 1.0
-2.0
1.0 1.0
2.0 1.0
Market C_Service 2_10_Process & Send (All)_Reconciliation_PAY
Market C_Service 2_7_Forward_Question_CS
-1.0 -1.0
-1.0
1.0 1.0
1.0 1.0 1.0
-1.0
-1.0
1.0
Market C_Service 2_8_Receive, Analyze & Send_Question_INFO
-2.0
-1.0
-1.0
2.0 1.0
2.0 1.0
1.0 1.0 -1.0 1.0 -1.0
-1.0
Market C_Service 2_6_Send Reply_Question_CS
-1.0
1.0
1.0 1.0
1.0 1.0
-1.0
Market C_Service 2_3_Create_Code_AU
2.0 1.0
1.0 1.0
-1.0
2.0 1.0
-1.0 -1.0 1.0 -1.0
-1.0
-1.0
-2.0
1.0 1.0
1.0 1.0
-1.0
-1.0
1.0
1.0
-1.0
-1.0
Market C_Service 2_5_Receive & Analyze_Question_CS
-1.0 -1.0
-2.0
1.0 2.0
Market C_Service 2_4_Process & Send _Event_INFO
1.0 1.0 1.0
2.0
1.0 1.0
1.0
-1.0
-1.0
1.0 1.0 1.0
2.0
-2.0 1.0 1.0 -1.0 1.0
1.0
-1.0 1.0 -2.0
1.0 1.0
1.0 1.0
1.0 1.0
1.0 1.0
-1.0
-1.0
2.0 1.0
2.0 1.0
-1.0
Market C_Service 2_2_Request_Code Creation_INFO
Market C_Service 1_14_Process & Send _Instruction_INST
Market C_Service 2_1_Receive & Analyze_Info_INFO
Market C_Service 1_12_Forward_Instruction_CS
Market C_Service 1_13_Request_Instruction Documentation_CS
Market C_Service 1_11_Receive, Analyze & Send_Instruction_INFO
Market C_Service 1_10_Forward_Instruction_INST
Market C_Service 1_8_Forward_Answer_CS
1.0 2.0
1.0 1.0
1.0
1.0 1.0
2.0 1.0
Market C_Service 1_9_Receive & Analyze_Instruction_INST
Market C_Service 1_6_Forward_Question_CS
Market C_Service 1_7_Receive, Analyze & Send_Question_INFO
Market C_Service 1_5_Send Reply_Question_CS
Market C_Service 1_4_Receive & Analyze_Question_CS
Market C_Service 1_2_Request_Info Clarification_INFO
Market C_Service 1_3_Process & Send _Event_INFO
DSM
Market C_Service 1_1_Receive & Analyze_Info_INFO
Figure 5.19 demonstrates the dependencies between jobs due to the above attributes.
Market C_Service 3_18_Receive, Analyze & Send_Problem_REC
involved, involves risk).
Page 64
1.0
1.0
Ch a pt er 5: Methodology followed and Case Study
For the first identified cell the structural views of jobs due to process, functions,
service and attributes were combined. Subsequently, the rows and columns of the
aggregated matrix were rearranged in order to model scenarios 3a and 3b. The
resulted matrices for scenarios 3a and 3b are illustrated in Figure 5.20 and Figure
5.21, respectively
Figure 5.20: Weighted matrix with varying interaction types for scenario 3
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 65
Ch a pt er 5: Methodology followed and Case Study
Figure 5.21: Weighted matrix with varying interaction types for scenario 3b
Moreover, a clustering analysis was conducted in the aggregated matrix for the
identification of potential service cells and to ensure we had found the best structure
solution possible for the intra-cluster aggregate matrix (same procedure with intercluster analysis). The resulted matrix for the clustering analysis was, once more,
identical to the DSM matrix of Figure 5.20. This is an indication that scenario 3b is
the best structure. Following that we proceeded with the assessment of the available
scenarios against the four structural metrics of the previous section. The results of the
analysis are presented in Table 5.4.
Table 5.4: Intra-cluster assessment table
Intra-cluster
Structural
Views
Function
Service
# of
Clusters
6
3
Assessment Metrics
Coordination
Coverage4
Cost5
0.87
4752
0.426
10057
Measure of
effectiveness4
801.16
389.58
4
Higher scores are better
Lower scores are better
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
5
Page 66
Ch a pt er 5: Methodology followed and Case Study
Reviewing the results we can see that organizing work by function (scenario 3a)
within the first identified market cell outperform scenario 3b. This is, although
scenario 3a produced more clusters it seams to address the majority of job interactions
in a more efficient way. That is also evident for the examination of the corresponding
DSMs. Observing Figure 5.21 we see that a large number of job dependencies are
spread outside clusters. These imply a need for constant cross-boundary interactions
that can significantly harm coordination or cause reworks, raising the overall
complexity. On the other hand, Figure 5.21 involves well-defined clusters, which can
operate independently of each other. Moreover, complexity is easier controlled, as
there are fewer cross-boundary dependencies. Work is finished inside each group
without reaching for support from other clusters.
Taking into consideration the above assessment coupled with the result of the
clustering analysis for the aggregated intra-cluster matrix we conclude that organizing
work by Function within the first identified cell of the system reduces complexity
considerably (see Figure 5.22).
Figure 5.22: Best case scenario for intra-cluster structure
As a last step of our approach, a thorough investigation of each sub-cell was
conducted in order to analyze its content and evaluate its requirements based on
average Full Time Equivalents (FTEs) and average Learning Curve (LC)
characteristics. From Table 5.5, it is seen that the 1st sub-cell is assigned the task of
performing all client services (CS) of Market A, for all service types. Furthermore, its
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 67
Ch a pt er 5: Methodology followed and Case Study
average labor requirements amount to 3.37 FTEs who require 144 months of training
in order to perform the 16 jobs of the cell.
Based on this assessment, Table 5.5 reveals the requirements for all sub-cells. Based
on these, managers can extract safe conclusions concerning the structure of the
system. For example, one might notice that the functions of PAY, INST and REC
exhibit low requirement for FTEs and associated learning times. Thus, taking also into
consideration the fact that the content of the related jobs doesn’t differ significantly
(as opposed to that of NI), we can combine the jobs of these sub-cells into one new
cell capable of performing the three separate functions across all service types.
Table 5.5: Analysis of service sub-cells within first Market department
New Structure
# of Jobs in
cluster 1
50
# Intra-Cluster
Jobs
16
13
8
5
4
4
Cluster Definition
Services
ALL
ALL
Service 2 + Service3
Service 1 + Service3
Service 2 + Service3
Service 2 + Service3
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Task
CS
INFO
PAY
INST
NI
REC
FTEs
(day)
LC
(month)
3.37
3.63
1.76
0.38
0.99
1.24
144
123
75
33
42
36
Page 68
Ch a pt er 6: Conclusions and Further Work
6. Conclusions and Further Work
Over the past few years operations have witnessed a steady shift towards services.
However, the research interest showed by the academic community towards the
service sector, has been limited. Many attempts to address issues such as how should
work be organized in service operations, and which factors influence a firm’s choice
of organizational design have been mainly focused around service structure
taxonomies, the majority of which are not sufficient to describe the unique nature of
service operations. This thesis proposes a method for assessing service organizational
structures and for designing service cells. It also addresses issues concerning the
factors that need to be taken into account in the selection of appropriate service
delivery structures.
We started by conducting an extensive literature review in the field of service
operations and organizational design, identifying the factors that influence
organizational structure in service systems. Subsequently, we presented our
methodology that uses the Design Structure Matrix (DSM). DSM has proven to be an
efficient way of modeling and analyzing complex manufacturing systems; however, it
has not been used extensively in services. Lastly, applying our approach to a complex
case study we managed to reduce system’s complexity.
6.1. About the Research Method
The methodology presented in this thesis constitutes a novel approach for studying
and capitalizing on the interactions between service jobs. Based on our research,
service jobs form the basis for the organizational design of service systems. Our
proposed method documents the various job dependency types in multiple matrices
synthesized in the DSM. Subsequently, by rearranging the rows and the columns of
the matrix we are able to model different structures. Finally, comparing the resulting
matrices against four structural assessment metrics, we identify the structure that
reduces system complexity.
6.2. Research Results
Our research results suggest that each service is unique, and thus, the selection of
organizational structure is influenced by a number of design factors. In this thesis we
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 69
Ch a pt er 6: Conclusions and Further Work
tried to identify the most important ones. Furthermore, we illustrated that in addition
to the typical structures of organizing service delivery, firms could benefit from
hybrid structures, such as service cells.
Our research also indicated that the Design Structure Matrix may be an efficient way
of modeling complex service systems. Novertheless, manipulating DSM matrices can
become quite a demanding task.
Therefore, we strongly recommend the use of
specialized computer software to support this process.
The case study presented some interesting insights. For example, system performance
was significantly reduced due to the communication issues between functional
departments. Thus:
1. The grouping of highly interrelated jobs into distinct service cells may
significantly reduce system’s complexity.
Furthermore, in the case study, we illustrated that the functional structure currently
employed by the firm forces the jobs to move in series, with each job passing from
one functional department to the next. The handoffs and reworks associated with this
organization amplified complexity.
2. The coupling of jobs (i.e. parallel structure) based on robust information
exchange may outweigh the economies of scale of a series structure.
6.3. Future Research
This thesis employed the Design Structure Matrix methodology to analyze the
structure of a typical service setting. Nonetheless, the undertaken DSM research was
mainly based on qualitative characteristics of the system in question. Thus, we argue
that further research could concentrate on a more quantitative validation of the
extracted results based on simulation. Furthermore, it would be interesting if our
method were tested in various service industries. Lastly, in this study we used the
assumption that each service uses a single distribution channel. That is, the service
was available through direct sales. However, a service can be offered through many
channels, such as ATMs or the Internet. Thus, future research might benefit from the
development of models that consider alternative service distribution channels or
customer paths.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 70
Re fer en ce s
References
1. Apte, M. Uday, M. Cynthia Beath, and Chon-Huat Goh. "An analysis of the
Production Line versus the Case Manager Approach to Information Intensive
Services." Decision Sciences, 1999: 1105-1129.
2. Assad, A. A., S. B. Kramer, and B. K. Kaku. "Comparing Functional and Cellular
layouts: a simulation study based on standardization." International Journal of
Production Research 41, no. 8 (2003): 1639-1663.
3. Belhe, U., Kusiak, A.: Modeling Relationships Among Design Activities. ASME
Journal of Mechanical Design 118 (1996) 4, pp. 454-460.
4. Black , JT. "Designing Rules for Implementing the Toyota Production System."
International Journal of Production Research 45, no. 16 (2007): 3639-3664.
5. Brandes, U., M. Gaertler and D. Wagner. “Experiments on Graph Clustering
Algorithms.” ESA 2003, LNCS 2832, (2003): 568-578
6. Browning, R. Tyson. "Applying the Design Structure Matrix to System
Decomposition and Integration Problems: A Review and New Directions." IEEE
Transactions on Engineering Management, 2001: 292-306.
7. Buzacott, John A. "Service System Structure." International Journal of Production
Economics 68 (2000): 15-27.
8. Chase, Richard B., and David A. Tansik. "The Customer Contact Model for
Organization Structure." Management Science 29, no. 9 (1983): 1037-1050.
9. Chase, Richard B., Robert F. Jacobs, and Nicholas J. Aquilano. Operations
Management for Competitive Advantage. New York: McGraw-Hill/Irwin, 2006.
10. Chesbrough, Henry, and Jim Spohrer. "A Research Manifesto for Service Science."
Communications of the ACM 49, no. 7 (2006): 35-40.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 71
Re fer en ce s
11. Danilovic, Mike, and H. Borjesson. "Managing the Multiproject Environment." 3rd
Dependency
Structure
Matrix
(DSM)
International
Workshop.
Cambridge:
Massachusetts Institute of Technology, 2001.
12. Danilovic, Mike, and Tyson R. Browning. "Managing complex product development
projects with design structure matrices and domain mapping matrices." International
Journal of Project Management 25 (2007): 300-314.
13. Davenport, Thomas H., and Nitin Nohria. "Case Management and the Integration of
Labor." Sloan Management Review 34, no. 2 (1994): 11-23.
14. Edvardsson, B., A. Gustafsson, and I. Roos. "Servce Portraits in Service Research."
International Journal of Service Industry Management 16, no. 1 (2005): 107-121.
15. Fernandez, C. I. G. (1998): Integration Analysis of Product Architecture to Support
Effective Team Co-Location. Cambridge: Massachusetts Institute of Technology,
Master Thesis 1998
16. Frei, Frances X. "Breaking the Trade-Off Between Efficiency and Service." Harvard
Business Review, November 2006: 1-10.
17. Galbraith, J. R. Designing Organizations: An Executive Briefing on Strategy,
Structure, and Process. San Francisco: Jossey-Bass, 1995.
18. Gebala, D. A.; Eppinger, S. D. (1991): Methods for Analyzing Design Procedures. In:
Proceedings of the ASME Third International Conference in Design Theory and
Methodology, Miami. Miami, USA: ASME 1991, pp 227-233.
19. Gibson, James L., John M. Ivancevich, and James H. Donnelly. Gibson
Organizations: Behavior, Structure, Processes. McGraw-Hill/Irwin, 1997.
20. Hameri, Ari-Pekka. "Production Flow Analysis-Cases from Manufacturing and
Service Industry." International Journal of Production Economics 129 (2011): 233241.
21. Hayes, Robert H., and Steven C. Wheelwright. "Link Manufacturing Processes and
Product Life Cycles." Harvard Business Review 1, no. 57 (1979): 133-140.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 72
Re fer en ce s
22. Harvey, Jean, Louis A. Lefebvre, and Elizabeth Lefebvre. "Flexibility and technology
in services: a conceptual model." International Journal of Operations & Production
Management 17, no. 1 (1997): 29-45.
23. Hopp, Wallace J., and Mark L. Spearman. Factory Physics. 2nd Edition. New York:
McGraw-Hll , 2000.
24. Hopp, Wallace J., Seyed M. R. Iravani, and Fang Liu. "Managing White-Collar Work:
An Operations-Oriented Survey." Production and Operations Management 18, no. 1
(2009): 1-32.
25. Hopp, Wallace J., Seyed M. R. Iravani, and Yuen Y. Gigi. "Operations Systems with
Discretionalry Task Completion." Management Science 53, no. 1 (2007): 61-77.
26. International Monetary Fund, World Economic Outlook Database, April 2011:
Nominal GDP list of countries. Data for the year 2010
27. Kreimeyer, Matthias, Stefanie Braun, Matthias Gurtler, and Udo Lindemann.
"Entending Multiple Domain Matrices to Allow for the Modeling of Boolean
Operators in Process Models." 17th International Conference on Engineering
Design. California: The Design Society. 1-13.
28. Kusiak, Andrew, and J. Wang. "Efficient Organizing of Design Activities."
International Journal of Production Research 31, no. 4 (1993): 753-769.
29. Levitt, T. "Production Line Approach to Services." Harvard Business Review 50, no.
5 (1972): 41-52.
30. Lievens , A., and R. K. Moenaert. "Communication Flows During Financial Service
Innovation." International Journal of Bank Marketing 19, no. 2 (2001): 68-88.
31. Lindemann, Udo, Maik Maurer, and Thomas Braun. Structural Complexity
Management: An approach for the field of product design. Berlin: Springer, 2009.
32. McCord, Kent R, (1993). Managing the Integration Problem in Concurrent
Engineering. Cambridge: Massachusetts Institute of Technology, Master Thesis 1993
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 73
Re fer en ce s
33. McCormick, J. W. T.; Schweizer, P. J.; White, T. W.: Problem Decomposition and
Data Reorganization by a Clustering Technique. Operations Research 20 (1972) 5,
pp. 993-1009
34. Metters, Richard, and Vicente Vargas. "A typology of de-coupling strategies in mixed
services." Journal of Operations Management (2000): 663-682.
35. Nesheim, Torstein. “Service Management and Organizational Design.” Scandinavian
Journal of Management 6, no. 3 (1990): 181-195.
36. Pagell, Mark, and Steven A. Melnyk. "Assessing the Impact of Alternative
Manufacturing Layouts in a Service Setting." Journal of Operations Management 22
(2004): 413-429.
37. Pimmler, Thomas U., and Steven D. Eppinger. "Integration Analysis of Product
Decompositions." ASME Design Theory an Methodology Conference. Minneapolis:
ASME, 1994.
38. Pinker, J. Edieal, and A. Robert Shumsky. "The Efficiency-Quality Trade-Off of
Cross- Trained Workers." Manufacturing & Service Operations Management 2, no. 1
(2000): 32-48.
39. Ponsignon, F., P. A. Smart, and R. S. Maull. "Service Delivery System Design:
Characteristics and Contingencies." International Journal of Production Management
31, no. 3 (2011): 324-349.
40. Shafer, Scott M., and John M. Charnes. "Cellular Versus Functional Layouts Under a
Variety of Shop Operation Conditions." Decision Sciences 24, no. 3 (1993): 665-682.
41. Steward, D. "The Design Structure System: A Method for Managing the Design of
Complex Systems." IEEE Transaction on Engineering Management 3, no. 28 (1981):
321-342.
42. Swank, Cynthia Karen. "The Lean Service Machine." Harvard Business Review,
October 2003: 123-129.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 74
Re fer en ce s
43. Thebeau, R. E. (2001): Knowledge Management of System Interfaces and
Interactions for Product Development Processes. Cambridge: Massachusetts Institute
of Technology, System Design & Management Program, Master Thesis 2001
44. Tompkins, James A., John A. White, Yavuz A. Bozer, and J. M. A. Tanchoco.
Facility Planning. 3rd Edition. John Wiley & Sons, Inc., 2003.
45. Zomerdijk, G. Leonieke, and Jan de Vries. "Structuring front office and back office
work in service delivery systems." International Journal of Operations & Production
Management, 2007: 108-131.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 75
Appen di ces
APPENDICES
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 76
Appen di ces
Appendix A : The Clustering Algorithm
For our approach presented in Chapter 5 we use the clustering algorithm of Thebeau
(2001). This algorithm is based on the clustering algorithm developed by Fernandez.
For a detailed description, refer to the thesis of Fernandez, (1999). Below we present
the steps of the algorithm:
1. Each element is initially placed in its own cluster (e.g. element a forms a
cluster A that includes only itself. Thus there are initially as many clusters as
the number of elements)
2. Calculate the initial Coordination Cost of the Cluster Matrix as described
below
3. Randomly choose an element
4. Calculate a bid value from each cluster for the selected element as described
below
5. Randomly choose a number between 1 and rand_bid (algorithm parameter)
6. The selected element temporarily becomes a member of the cluster with the
highest bid (use second highest bid if step 5 is equal to rand_bid)
7. Calculate the new Coordination Cost
8. Randomly choose a number between 1 and rand_accept (algorithm parameter)
9. If the new value of the Coordination Cost is lower than the previous
Coordination Cost, or the number chosen in step 8 is equal to rand_accept,
make the change permanent otherwise make no changes
10. Go back to step 3 and repeat until a set number of times is reached.
The Coordination Cost of the Cluster Matrix of steps 2, and 7 is calculated as
follows:
If both elements i and j are in any cluster k then,
size
Cl
j 1
k 1
Coordinati onCost (element i )   DSM (i, j )  DSM ( j, i)  *  cl _ size(k ) pow_ cc
else,
size
Coordinati onCost (element i )   DSM (i, j )  DSM ( j, i)  * size pow_ cc
j 1
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 77
Appen di ces
size
TotalCoordinationCos t   Coordinati onCost (element i )
i 1
Where:
size = the size of the DSM (i.e. the number of elements)
DSM(i,j) = the value of interaction between element i and j in the DSM.
Cl = the maximum number of clusters or element that the algorithm explores.
Thus, Cl is equal to size
cl_size(k) = the number of elements in cluster k
powcc = A parameter that is used to penalize the size of cluster (i.e. larger values
of powcc create smaller clusters)
The bid value from cluster k for the randomly selected element t in step 4 is
calculated as follows:
DSM (t, j)  DSM ( j, t )
Bid (cluster , element )  
size
k
t
j 1
pow_ dep
cl _ size(k )
* CL _ MAT (k , j )

pow_ bid
Where:
Bid(clusterk,elementt)= bid from cluster k to random element t
size = the size of the DSM
DSM(t, j) = the value of interaction between the randomly selected t and element j
cl_size(k)= the number of elements contained in cluster k
CL_MAT(k,j)= is a 0-1 variable. It takes the value of 1 when task j is present in
cluster k
pow_dep = exponent that emphasizes interactions
pow_bid = exponent that penalizes the size of the cluster
In order to clarify how the algorithm can be adjusted to each specific case through
its variable,s we present below the most important variables and their significance:
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 78
Appen di ces
1. pow_cc: Penalizes the size of clusters (i.e. smaller clusters for higher values of
pow_cc)
Note: The difficulty of managing jobs within the cluster increases with the
number of jobs. This increase can be linear (i.e. =1), quadratic (i.e. =2)….etc.
2. pow_bid: Penalizes the size of cluster
Note: A large value e.g. 3 discourages the formation of large clusters and
encourages the formation of clusters with similar size, whereas when using a
value as small as 0, the cluster size becomes unimportant for the bid and
clusters can have a large range of sizes.
3. pow_dep: Emphasizes interactions
Note: Controls the importance given to strong interactions over weak ones.
For example, a value of 0.5 makes different interactions more similar, while a
large value, e.g. 3, increases the difference of importance given to strong
interactions.
4. max_cluster_size: The max number of jobs a cluster may contain
Note:
Prevents
the
formation
of
ancluster
containing
more
than
max_cluster_size. It is used if theuser desires to restrict the number of jobs
within each cluster.
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 79
Appen di ces
Appendix B : Partitioning
A Partitioning algorithm reorders the rows and columns of the DSM with the
objective of relocating dependencies on one side of the diagonal (i.e. converting a
DSM into an upper-triangular or lower-triangular matrix). Such a matrix arrangement
implies that no feed-back loops exist in the system. However, such an alignment in
the majority of cases is unrealistic. Thus, partitioning tries to arrange as many
dependencies at the one side of the diagonal, and the remaining at least as close as
possible to the diagonal. Of course the latter signify feed-back loops.
In activity-based DSMs, the matrix resulting after the realignment of rows and
columns indicates an appropriate sequence of process-step execution. For static DSMs
partitioning can identify groups of elements suitable for modular design. Figure B.1
demonstrates an application of the partitioning algorithm for an optimized sequential
arrangement of activities in an automobile design process (Kusiak and Wang, 1993).
Figure B.1: Activity-based DSM of an automobile design process
Source: “Efficient organizing of design activities”, (Kusiak and Wang, 1993)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 80
Appen di ces
Figure B.2: Partitioned matrix of activity-based DSM
Source: “Efficient organizing of design activities”, (Kusiak & Wang, 1993)
Gebala and Eppinger (1991) and Kussiak and Wang (1993) have presented their
approaches for the realignment process in a step-by-step algorithm.
Banding and Tearing
As depicted earlier, Clustering and Partitioning are the most conventional algorithms
for matrix realignment and analysis. Nevertheless, they are not considered as panacea.
There have been a variety of other methods for obtaining structural characteristics
from DSMs, including Banding and Tearing. Banding can reveal groups of elements
that can be processed independently from each other by applying light and dark bands
to the matrix (ignoring feedback marks). Thus, elements that can be processed in
parallel are assigned to the same band. On the other hand, Tearing indicates the set of
feedback marks (i.e. tears) that if removed from the matrix (and then the matrix is
repartitioned) an optimized structure of the system can be obtained. Both banding and
tearing approaches require the partitioning of the matrix before their application. For
more information on these methods, please refer to (Browning, 2001).
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 81
Appen di ces
Appendix C : Deduction of Indirect Dependencies
Lindemann et al. (2009) presented the mathematical approach for systematically
mapping indirect dependencies from available information. They identified six
possible cases for computing an aggregated DSM within an MDM. Generally, the
different scenarios include the computation of the derived DSMs using one native
DMM (Figure C.3, differentiating the direction of the DMM mapping as cases 1 and
2), two DMM (Figure C.3, case 3), one DSM and one DMM (Figure C.4,
differentiating the direction of the DMM mapping as cases 4 and 5) and one DMM
and one DSM (Figure C.4, case 6).
Single Native DMM (Cases 1 & 2)
DSMagg= DMMnatT · DMMnat
Two Native DMMs (Case 3)
DSMagg=DMMnat,input · DMMnat,output
Figure C.3: Possible cases 1 to 3 for computing an aggregated DSM within a MDM
Source: “Structural Complexity Management”, (Lindemann et al., 2009)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 82
Appen di ces
Native DSM and Native DMM (Case 4 & 5)
DSMagg= DMMnatT · DMMnat
Native DSM and two Native DMMs (Case 6)
DSMagg=DMMnat,input · DMMnat,output
Figure C.4: Possible cases 4 to 6 for computing an aggregated DSM within a MDM
Source: “Structural Complexity Management”, (Lindemann et al.,, 2009)
For example the left part of Figure C.3 depicts the logic for deriving indirect
dependencies between jobs via persons. The corresponding DMM must be filled with
data on existing dependencies between jobs and persons (in our case information
about which jobs is person 1 responsible for). Then applying the available
mathematical computation we can generate the aggregate DSM at the left. The
derived dependencies (in parentheses) illustrate how jobs are linked due to their
mutual interdependence to people (job 1 and job 2 are linked as they are performed by
the same person).
Such an approach is advantageous and further extends the value of the MDM. Though
the application of these computations the user can easily build several views of the
system in question (i.e. the critical domain) reliant each time on different domains
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 83
Appen di ces
Appendix D : Case study Information Acquisition Data
Table D.1 and Table D.2 illustrate the acquired data of the case study. Table D.1
includes details of each job independently, such as general information (name,
market, service, function), it’s attributes (orange columns) and other quantitative data
(blue columns) Table D.2 depicts the average demand for each of the three case study
services.
Average Demand (monthly)
Av.Process Time
Average FTEs (day)
Learning Curve (months)
1.5
0.0
6.0
302
3.0
0.1
3.0
302
4.0
0.1
9.0
302
8.0
0.3
9.0
302
1.0
0.0
3.0
302
15.0
0.5
6.0
302
3.0
0.1
9.0
302
3.0
0.1
3.0
302
1.0
0.0
3.0
302
15.0
0.5
3.0
1
302
3.0
0.1
1.5
1
302
1.5
0.0
6.0
302
4.0
0.1
3.0
199
3.0
0.1
6.0
199
1.5
0.0
3.0
-1
199
10.0
0.2
12.0
-1
199
3.6
0.1
9.0
199
4.0
0.1
6.0
199
8.0
0.2
9.0
INFO
(E)
1
1
Market A
Service 1
Request
INFO
(E)
1
Market A
Service 1
Process & Send
INFO
(I)
Market A
Service 1
Receive & Analyze
CS
(E)
1
Market A
Service 1
Send Reply
CS
(E)
1
Market A
Service 1
CS
(I)
Market A
Service 1
Forward
Receive, Analyze &
Send
INFO
(I)
Market A
Service 1
Forward
CS
(E)
1
Market A
Service 1
Receive & Analyze
INST
(E)
1
Market A
Service 1
Forward
INST
(I)
Market A
Service 1
Receive, Analyze &
Send
INFO
(I)
Market A
Service 1
Forward
CS
(E)
Market A
Service 1
Request
CS
(E)
Market A
Service 1
Process & Send
INST
(I)
Market A
Service 2
Receive & Analyze
INFO
(E)
Market A
Service 2
Request
INFO
(I)
Market A
Service 2
Create
AU
(I)
Market A
Service 2
Process & Send
INFO
(I)
Market A
Service 2
Receive & Analyze
CS
(E)
1
Market A
Service 2
Send Reply
CS
(E)
1
Owner
Receive & Analyze
Market
Service 1
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Risk
302
Market A
Discretion
3.0
Diagnosis
0.1
Cust. Contact
3.0
Job
302
Service
Internal/ External
Table D.1: Worksheet
-1
1
-1
-1
-1
-1
1
1
-1
-1
-1
1
1
1
-1
-1
Page 84
Market A
Service 2
INFO
(I)
Forward
CS
(E)
PAY
(I)
REC
(I)
Process & Send
(All)
Receive, Analyze &
Send
Market A
Service 2
Market A
Service 2
Market A
Service 2
Process & Send
PAY
(I)
Market A
Service 2
Forward
PAY
(I)
Market A
Service 2
Send Reply
CS
(E)
PAY
(I)
REC
(I)
AU
(I)
Process & Send
(All)
Receive, Analyze &
Send
Receive, Analyze &
Send
Receive, Analyze &
Send
0.0
3.0
199
15.0
0.3
6.0
199
3.0
0.1
9.0
199
5.0
0.1
9.0
199
15.0
0.3
9.0
199
5.0
0.1
9.0
199
1.0
0.0
3.0
199
8.0
0.2
9.0
199
5.0
0.1
9.0
1
199
15.0
0.3
9.0
1
199
15.0
0.3
9.0
185
15.0
0.3
12.0
185
1.5
0.0
3.0
-1
Risk
1.0
Discretion
199
Diagnosis
Cust. Contact
Internal/ External
Owner
(I)
Learning Curve (months)
Service 2
CS
Average FTEs (day)
Market A
Forward
Receive, Analyze &
Send
Av.Process Time
Service 2
Average Demand (monthly)
Market A
Job
Service
Market
Appen di ces
-1
1
-1
1
-1
1
Market A
Service 2
Market A
Service 2
Market A
Service 2
Market A
Service 3
Market A
Service 3
Request
INFO
(I)
Market A
Service 3
Create
AU
(I)
-1
185
1.5
0.0
12.0
Market A
Service 3
Process & Send
INFO
(I)
-1
185
4.2
0.1
12.0
Market A
Service 3
Receive & Analyze
CS
(E)
1
185
4.0
0.1
9.0
Market A
Service 3
Send Reply
CS
(E)
1
185
8.0
0.2
9.0
Market A
Service 3
Forward
CS
(I)
185
1.0
0.0
9.0
Market A
Service 3
Receive, Analyze &
Send
INFO
(I)
185
15.0
0.3
12.0
Market A
Service 3
Forward
CS
(E)
185
3.0
0.1
9.0
Market A
Service 3
Process & Send
INST
(I)
185
5.6
0.1
9.0
Market A
Service 3
(I)
185
1.0
0.0
3.0
Market A
Service 3
PAY
(I)
185
5.0
0.1
9.0
Market A
Service 3
Forward
Process & Send
(All)
Receive, Analyze &
Send
INST
REC
(I)
185
15.0
0.3
12.0
Market A
Service 3
Process & Send
PAY
(I)
185
7.0
0.1
12.0
Market A
Service 3
Forward
PAY
(I)
185
1.0
0.0
3.0
Market A
Service 3
Send Reply
CS
(E)
185
8.0
0.2
9.0
PAY
(I)
185
5.0
0.1
12.0
REC
(I)
185
15.0
0.3
12.0
Market A
Service 3
Market A
Service 3
Process & Send
(All)
Receive, Analyze &
Send
INFO
-1
(I)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
1
-1
1
-1
-1
-1
-1
1
-1
-1
1
-1
1
-1
1
Page 85
Average Demand (monthly)
Av.Process Time
Average FTEs (day)
Learning Curve (months)
1
776
3.0
0.2
3.0
776
1.5
0.1
6.0
776
3.0
0.2
3.0
776
4.0
0.3
9.0
776
8.0
0.7
9.0
776
1.0
0.1
3.0
776
15.0
1.2
6.0
776
3.0
0.2
9.0
776
3.0
0.2
3.0
776
1.0
0.1
3.0
776
15.0
1.2
3.0
1
776
3.0
0.2
1.5
1
776
1.5
0.1
6.0
776
4.0
0.3
3.0
583
3.0
0.2
6.0
583
1.5
0.1
3.0
-1
583
10.0
0.6
12.0
-1
583
3.6
0.2
9.0
583
4.0
0.2
6.0
583
8.0
0.5
9.0
583
1.0
0.1
3.0
583
15.0
0.9
6.0
583
3.0
0.2
9.0
583
5.0
0.3
9.0
583
15.0
0.9
9.0
583
5.0
0.3
9.0
583
1.0
0.1
3.0
583
8.0
0.5
9.0
583
5.0
0.3
9.0
583
15.0
0.9
9.0
AU
(I)
Market B
Service 1
Receive & Analyze
INFO
(E)
1
Market B
Service 1
Request
INFO
(E)
1
Market B
Service 1
Process & Send
INFO
(I)
Market B
Service 1
Receive & Analyze
CS
(E)
1
Market B
Service 1
Send Reply
CS
(E)
1
Market B
Service 1
CS
(I)
Market B
Service 1
Forward
Receive, Analyze &
Send
INFO
(I)
Market B
Service 1
Forward
CS
(E)
1
Market B
Service 1
Receive & Analyze
INST
(E)
1
Market B
Service 1
Forward
INST
(I)
Market B
Service 1
Receive, Analyze &
Send
INFO
(I)
Market B
Service 1
Forward
CS
(E)
Market B
Service 1
Request
CS
(E)
Market B
Service 1
Process & Send
INST
(I)
Market B
Service 2
Receive & Analyze
INFO
(E)
Market B
Service 2
Request
INFO
(I)
Market B
Service 2
Create
AU
(I)
Market B
Service 2
Process & Send
INFO
(I)
Market B
Service 2
Receive & Analyze
CS
(E)
1
Market B
Service 2
Send Reply
CS
(E)
1
Market B
Service 2
Forward
CS
(I)
Market B
Service 2
Receive, Analyze &
Send
INFO
(I)
Market B
Service 2
CS
(E)
Market B
Service 2
PAY
(I)
Market B
Service 2
REC
(I)
Market B
Service 2
Forward
Process & Send
(All)
Receive, Analyze &
Send
Process & Send
PAY
(I)
Market B
Service 2
Forward
PAY
(I)
Market B
Service 2
Send Reply
CS
(E)
PAY
(I)
REC
(I)
Market B
Service 2
Market B
Service 2
Process & Send
(All)
Receive, Analyze &
Send
Owner
Receive, Analyze &
Send
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Risk
12.0
Service 3
Discretion
0.3
Market A
Diagnosis
15.0
Cust. Contact
185
Job
Internal/ External
1
Service
Market
Appen di ces
-1
1
-1
-1
-1
-1
1
1
-1
-1
-1
1
1
1
-1
-1
-1
-1
1
-1
1
-1
1
-1
1
Page 86
Market B
Service 3
Request
INFO
(I)
Market B
Service 3
Create
AU
(I)
Market B
Service 3
Process & Send
INFO
(I)
Market B
Service 3
Receive & Analyze
CS
(E)
1
Market B
Service 3
Send Reply
CS
(E)
1
Market B
Service 3
Forward
CS
(I)
Market B
Service 3
Receive, Analyze &
Send
INFO
(I)
Market B
Service 3
Forward
CS
(E)
Market B
Service 3
Process & Send
INST
(I)
Market B
Service 3
INST
(I)
Market B
Service 3
PAY
(I)
Market B
Service 3
Forward
Process & Send
(All)
Receive, Analyze &
Send
REC
(I)
Market B
Service 3
Process & Send
PAY
(I)
Market B
Service 3
Forward
PAY
(I)
Market B
Service 3
Send Reply
CS
(E)
PAY
(I)
REC
(I)
AU
(I)
9.0
475
15.0
0.8
12.0
475
1.5
0.1
3.0
-1
475
1.5
0.1
12.0
-1
475
4.2
0.2
12.0
475
4.0
0.2
9.0
475
8.0
0.4
9.0
475
1.0
0.1
9.0
475
15.0
0.8
12.0
475
3.0
0.2
9.0
475
5.6
0.3
9.0
475
1.0
0.1
3.0
475
5.0
0.3
9.0
475
15.0
0.8
12.0
475
7.0
0.4
12.0
475
1.0
0.1
3.0
475
8.0
0.4
9.0
475
5.0
0.3
12.0
1
475
15.0
0.8
12.0
1
475
15.0
0.8
12.0
1
399
3.0
0.1
3.0
399
1.5
0.1
6.0
399
3.0
0.1
3.0
399
4.0
0.2
9.0
399
8.0
0.3
9.0
399
1.0
0.0
3.0
399
15.0
0.6
6.0
399
3.0
0.1
9.0
399
3.0
0.1
3.0
399
1.0
0.0
3.0
Risk
0.9
Discretion
15.0
Diagnosis
583
1
(I)
1
-1
1
-1
-1
-1
-1
1
-1
-1
1
-1
1
Market B
Service 3
Market B
Service 3
Market B
Service 3
Market C
Service 1
Receive & Analyze
INFO
(E)
1
Market C
Service 1
Request
INFO
(E)
1
Market C
Service 1
Process & Send
INFO
(I)
Market C
Service 1
Receive & Analyze
CS
(E)
1
Market C
Service 1
Send Reply
CS
(E)
1
Market C
Service 1
Forward
CS
(I)
Market C
Service 1
Receive, Analyze &
Send
INFO
(I)
Market C
Service 1
Forward
CS
(E)
1
Market C
Service 1
Receive & Analyze
INST
(E)
1
Market C
Service 1
Forward
INST
(I)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Learning Curve (months)
Service 3
Average FTEs (day)
Market B
INFO
(I)
Av.Process Time
Service 2
Process & Send
(All)
Receive, Analyze &
Send
Receive, Analyze &
Send
AU
Cust. Contact
Market B
Average Demand (monthly)
Receive, Analyze &
Send
Receive, Analyze &
Send
Internal/ External
Owner
Job
Service
Market
Appen di ces
-1
-1
1
-1
-1
1
-1
-1
Page 87
Forward
CS
(E)
Market C
Service 1
Request
CS
(E)
Market C
Service 1
Process & Send
INST
(I)
Market C
Service 2
Receive & Analyze
INFO
(E)
Market C
Service 2
Request
INFO
(I)
Market C
Service 2
Create
AU
(I)
Market C
Service 2
Process & Send
INFO
(I)
Market C
Service 2
Receive & Analyze
CS
(E)
1
Market C
Service 2
Send Reply
CS
(E)
1
Market C
Service 2
Forward
CS
(I)
Market C
Service 2
Receive, Analyze &
Send
INFO
(I)
Market C
Service 2
Forward
CS
(E)
PAY
(I)
REC
(I)
Process & Send
(All)
Receive, Analyze &
Send
Market C
Service 2
Market C
Service 2
Market C
Service 2
Process & Send
PAY
(I)
Market C
Service 2
Forward
PAY
(I)
Market C
Service 2
Send Reply
CS
(E)
PAY
(I)
REC
(I)
AU
(I)
Process & Send
(All)
Receive, Analyze &
Send
Receive, Analyze &
Send
Receive, Analyze &
Send
Learning Curve (months)
Service 1
Average FTEs (day)
Market C
Av.Process Time
(I)
Average Demand (monthly)
INFO
Risk
Receive, Analyze &
Send
Discretion
Service 1
Diagnosis
Cust. Contact
Internal/ External
Job
Market C
Owner
Service
Market
Appen di ces
1
-1
-1
399
15.0
0.6
3.0
1
399
3.0
0.1
1.5
1
399
1.5
0.1
6.0
399
4.0
0.2
3.0
66
3.0
0.0
6.0
66
1.5
0.0
3.0
-1
66
10.0
0.1
12.0
-1
66
3.6
0.0
9.0
66
4.0
0.0
6.0
66
8.0
0.1
9.0
66
1.0
0.0
3.0
66
15.0
0.1
6.0
66
3.0
0.0
9.0
66
5.0
0.0
9.0
66
15.0
0.1
9.0
66
5.0
0.0
9.0
66
1.0
0.0
3.0
66
8.0
0.1
9.0
66
5.0
0.0
9.0
1
66
15.0
0.1
9.0
1
66
15.0
0.1
9.0
244
15.0
0.4
12.0
244
1.5
0.0
3.0
-1
1
1
1
-1
-1
-1
-1
1
-1
1
-1
1
Market C
Service 2
Market C
Service 2
Market C
Service 2
Market C
Service 3
Market C
Service 3
Request
INFO
(I)
Market C
Service 3
Create
AU
(I)
-1
244
1.5
0.0
12.0
Market C
Service 3
Process & Send
INFO
(I)
-1
244
4.2
0.1
12.0
Market C
Service 3
Receive & Analyze
CS
(E)
1
244
4.0
0.1
9.0
Market C
Service 3
Send Reply
CS
(E)
1
244
8.0
0.2
9.0
Market C
Service 3
Forward
CS
(I)
244
1.0
0.0
9.0
Market C
Service 3
Receive, Analyze &
Send
INFO
(I)
244
15.0
0.4
12.0
Market C
Service 3
Forward
CS
(E)
244
3.0
0.1
9.0
INFO
-1
(I)
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
1
-1
1
-1
-1
1
-1
-1
Page 88
Market C
Service 3
INST
(I)
Market C
Service 3
PAY
(I)
Market C
Service 3
Forward
Process & Send
(All)
Receive, Analyze &
Send
REC
(I)
Market C
Service 3
Process & Send
PAY
(I)
Market C
Service 3
Forward
PAY
(I)
Market C
Service 3
CS
(E)
Market C
Service 3
PAY
(I)
Market C
Service 3
REC
(I)
Market C
Service 3
Send Reply
Process & Send
(All)
Receive, Analyze &
Send
Receive, Analyze &
Send
AU
(I)
Service
Type
5.6
0.1
9.0
244
1.0
0.0
3.0
244
5.0
0.1
9.0
244
15.0
0.4
12.0
244
7.0
0.2
12.0
244
1.0
0.0
3.0
244
8.0
0.2
9.0
244
5.0
0.1
12.0
1
244
15.0
0.4
12.0
1
244
15.0
0.4
12.0
Discretion
244
Diagnosis
-1
-1
1
-1
1
-1
Table D.2: Average Demand for Service 1-3 across three Markets
Creation month
Global
market
3
4
5
6
7
8
Service 1
9
10
11
Grand
Total
Average
3022
3068
2621
1456
657
977
477
592
423
13293
1477.0
A
815
828
707
393
177
264
129
160
114
3587
398.5
B
1588
1613
1378
765
345
514
251
311
222
6987
776.3
C
618
628
536
298
134
200
98
121
87
2720
302.2
3022
3068
2621
1456
657
977
477
592
423
13293
1477.0
A
106
33
91
58
46
217
13
21
9
594
66.0
B
461
573
631
666
517
1190
392
518
295
5243
582.6
C
Total – Service 1
Service 2
Learning Curve (months)
(I)
Average FTEs (day)
INST
Av.Process Time
Process & Send
Average Demand (monthly)
Service 3
Risk
Market C
Cust. Contact
Internal/ External
Owner
Job
Service
Market
Appen di ces
198
185
205
233
271
337
201
104
55
1789
198.8
Total – Service 2
765
791
927
957
834
1744
606
643
359
7626
847.3
Service 3
A
343
269
500
424
190
154
160
110
43
2193
243.7
B
635
369
552
575
389
996
335
311
110
4272
474.7
C
197
196
160
191
237
409
125
111
37
1663
184.8
1175
834
1212
1190
816
1559
620
532
190
8128
903.1
4962
4693
4760
3603
2307
4280
1703
1767
972
29047
3227.4
Total – Service 3
Grand
Total
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 89
Appen di ces
Appendix E Options for Converting a Process Model into DSM
In order to present how a process model can be transferred to a DSM (for an extensive
description of each method refer to Kreimeyer et al., 2009) we will use a sample
design process adapted from Belhe and Kusiak (1996). The process model is
illustrated in Figure E.1 .
Figure E.1 : Sample design process (Belhe & Kusiak, 1996)
The rectangles constitute design tasks from 1 to 7 and the circles logic operators
(AND, OR, XOR).
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 90
Appen di ces

Option 1: Resolve all logical connections
This option involves creating individual matrices for each process path (Figure
E.2 ). Although this seams a simple choice, many different networks are generated
and is only practical for small models with few logic paths.
Figure E.2 : Conversions of process model according to option 1

Option 2: Neglect the operators
In this option, no decision point is taken into consideration, and the related
connections are converted into simple edges. This way, the basic structure of
the process can be easily analyzed, but dynamic information is neglected.
Figure E.3 : Conversion of process model according to option 2
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 91
Appen di ces

Option 3: Decisions as probabilities for related paths
For each decision point a probability is given for taking each path. This
approach enables the process to be modeled in greater detail. However, this
option presupposes the existence of run-time data.
Figure E.4 : Corversion of process model according to option 3

Option 4: Logic operators as additional entities
Operators are treated as additional entities of the DSM. Thus, they lose their
meaning. The disadvantage of this approach is that it extends the size of the
matrix in order to include the additional entries of the decision operators.
Moreover the type of operator becomes irrelevant.
Figure E.5 : Conversion of process model according to option 4
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 92
Appen di ces

Option 5: Logic operators as additional entities retaining their
characteristics
This approach turns the process model into a MDM in which one domain
maps the existence and connectivity of the connectors (J1-J3 domain), and
another describes the type of the connector (AND, OR, XOR domain).
Although this approach is the most complete for process modeling compared
to the other options, it is also the most complex.
Figure E.6 : Conversion of process model according to option 5
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 93
Appen di ces
Appendix F : Structural Metrics to assess modularity
Figure F.1: Example of clustered matrix
i.
Coverage: Coverage (C) of a graph clustering C is the fraction of intra-cluster
edges within the complete set of edges (Brandes et al., 2003).
cov erage(C) =
m (C )
m
=
m (C )
m (C ) + m(C)
where,
C= (C1, .....,Ck) a partition of the matrix
m (C): the number of intra-cluster edges
m (C): the number of inter-cluster edges
For example the coverage for Figure F.1 is 0,8
ii.
Coordination Cost: The total coordination cost of jobs (for details refer to
Appendix A).
iii.
Measure of Effectiveness: The measure of effectiveness of an array A is the
sum of the bond strengths in the array where the bond strength between two
nearest-neighbor elements is defined as their product
For a nonnegative M x N array with a0, j  a M 1, j  ai ,0  ai , N 1  0
iM i N

ME ( A)   aij ai , j 1  ai , j 1  ai 1, j  ai 1, j

i 1 i 1
For example the measure of effectiveness for figure F.1 is 23
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 94
Appen di ces
UNIVERSITY OF THE AEGEAN – DeOPSys Lab
Page 95