=Paper=
{{Paper
|id=Vol-2229/paper3
|storemode=property
|title=Case Study of Print Service Provider Activities: DEMO Methodology in Practice
|pdfUrl=https://ceur-ws.org/Vol-2229/paper3.pdf
|volume=Vol-2229
|authors=Cosmina Chișe,Jennek Geels
}}
==Case Study of Print Service Provider Activities: DEMO Methodology in Practice==
https://ceur-ws.org/Vol-2229/paper3.pdf
Case Study of Print Service Provider Activities: DEMO
Methodology in Practice
✉ Cosmina Chișe1 and Jennek Geels2
1 Océ Software SRL, Blvd. Mihai Viteazu 30B, 300222, Timisoara, Romania
cosmina.chise@oce.com
2 Océ-Technologies B.V., St. Urbanusweg 43, 5900 MA, Venlo, Netherlands
jennek.geels@oce.com
Abstract. The DEMO methodology was devised to facilitate organizational
change, by providing means to model the essence of an organization. The inten-
tion of this paper is to extend the reach of this methodology into the printing
industry realm, modeling scenarios of Print Service Provider customers and em-
ployees interacting with each other, using a print workflow management software
system, PRISMAdirect. The scenarios were modeled in terms of the complete
transaction pattern, the Construction Model and the Process Model. An improve-
ment idea emerged for the delegation of responsibilities, while complex excep-
tion handling scenarios shall be further investigated.
Keywords: Enterprise Engineering, Printing, DEMO.
1 Introduction
Organizations nowadays are facing changes more frequently than before, due to con-
tinuously evolving market needs. Professor Jan L.G. Dietz proposes the DEMO (De-
sign and Engineering Methodology for Organizations) methodology, in the EE (Enter-
prise Engineering) discipline [1], to better manage the complexity of organizations.
The structure of Print Service Providers (PSPs) ranges from family-owned shops
with a few employees and a few print engines to large manufacturing-like facilities,
having tens of employees working in shifts to keep offset presses and print engines
running 24X7. Production of various unique artifacts implies a dynamic, flexible work-
flow [2], increasing headcount and device types. In the early days, the customers
walked in and spoke to a front desk employee. To grow their customer base, PSPs take
orders in via multiple input channels: phone call, email, submission via web-to-print.
Océ, a Canon company, developed PRISMAdirect [3], a software system that fulfils
both requirements: print workflow management, and W2P (web-to-print).
Coordination and production acts [4] are present in any business, including PSPs,
although workflow software vendors primarily focus on production. In a PSP, produc-
tion refers to all manufacturing steps (e.g. printing, finishing). To keep the domain spe-
cific terminology for PSPs accurate, production in the DEMO meaning shall be denoted
by “execution” (phase of the transaction process [1]) in the remainder of the paper.
2
The triggers in the Process Model allow modeling automation of acts, important for
PSPs in dealing with many incoming orders, in order to fulfil the orders within the
deadlines set by Print Buyers.
Section 2 presents DEMO models and an implementation (PRISMAdirect) for a typ-
ical PSP workflow. More complex scenarios are discussed in section 3, while section 4
reveals conclusions and future work directions.
2 Models of PSP Scenarios
Typical scenarios from a PSP were modeled by means of the DEMO approach [5]. The
Construction Model is shown in Fig. 1, and Table 1 describes transaction results.
Fig. 1. Construction Model for a PSP environment
CA2 (Print Buyer) provides details of the desired print product(s): T1/rq. Depending
on the payment policy of the PSP, payment (T2) can be required upfront or pay-on-
delivery may be allowed. When PSPs work with cost centers, any order whose price
exceeds a threshold requires approval (T3).
Once an order has been accepted in the PSP, the preparing step (T4), e.g. imposition,
or design, gets content ready for production: printing (T5) and finishing (T6), e.g. cut-
ting, or folding. For booklet production, the operator (A5) may handle a printer with an
inline booklet maker, or there may be a separate finishing unit, requiring another oper-
ator (A6). For orders that need delivery (T8), the PSP usually contracts an external
shipping agent; however, there are PSPs that assign their own employees. Prior to ship-
ping, jobs are usually packaged (T7) into containers, e.g. envelopes, boxes.
3
The trigger concept (Process Model) is useful to model automation of payment re-
quest (T2/rq upon T1/rq) and promise (T2/pm upon T2/rq), since CA2 implicitly agreed
to pay the displayed price when placing the order. Wait conditions (Process Model) are
useful in many cases, e.g. finishing (T6) can only start after successful printing (T5).
Table 1. Transaction Product Table
Transaction kind Product kind
T1. Order Fulfilment P1. Order is fulfilled.
T2. Order Payment P2. The price of Order is paid.
T3. Order Approval P3. The price of Order is approved.
T4. Job Preparing P4. The job of Order is prepared.
T5. Job Printing P5. The job of Order is printed
T6. Job Finishing P6. The job of Order is finished
T7. Job Packaging P7. The job of Order is packaged.
T8. Order Shipping P8. The package(s) of Order is (are) shipped.
The transaction pattern coverage offered by PRISMAdirect was assessed, since the
software system had been designed without any knowledge of DEMO. The main con-
cept in PRISMAdirect [6] is the order, made of one or more jobs. A job is an instance
of a print product (e.g. booklet). The mapping of DEMO notions to PRISMAdirect is:
T1/rq: Order submission.
T1/dc: Request for change, via email, e.g. update file, due to content issues.
T1/pm: Accept (email may be sent to Print Buyer as a notification).
T1/da: Mark ready - order/job (ready for pick-up or shipping), option to send email.
T1/ac: implicit (upon order pick up or delivery).
T1/rj can be performed via phone call (outside the software system).
3 Discussion on Complex Scenarios from a PSP Environment
Scenarios of increasing complexity, involving revocation or delegation, were stud-
ied. In the authors’ experience, exception handling cases are the most difficult to model.
3.1 Delegation
A pay-on-delivery scenario involves delegation of responsibilities and requires more
granular delegations, at act level. Delegation is modeled in DEMO at transaction level.
The following delegations are needed, since the A1 is not present at CA2’s house:
T8/ac: CA2 (Print Buyer) accepts the Order Shipping (T8). The acceptance means
the product was delivered at the correct address.
T1/da: CA8 (Order Shipper) declares the Order Fulfilment (T1) towards CA2.
T2/ac: CA8 (Order Shipper) accepts Payment on behalf of A1 (Order Fulfiller).
4
This enables a stricter control of role authorization to perform certain acts, within
the same transaction, e.g. CA8 should not be allowed to perform T1/pm, but only T1/da.
3.2 Exception handling cases
Simple exception handling cases modeled by revocations of acts are described below:
Revoke request: CA2 (Print Buyer) uploads the wrong file and wishes to fix it later.
Revoke promise: The media required for a certain print product becomes out of stock
after production started. In this case, A1 revokes the promise (T1/pm) and can sug-
gest production on a different media, also explaining the impact on the end product.
Revoke declare: CA2 (Print Buyer) discovers that a few books contain unacceptable
stains inside. The order is rejected (T1/rj) and a dialog between CA2 and A1 (Order
Fulfiller) follows. In case A1 admits to having delivered a faulty product, the declare
(T1/da) is revoked and, if CA2 allows the revocation, the execution of T1 is redone.
It is important not to create a new instance of T1 for each revocation, since PSP
owners consider the conversation as one instance of a business process, regardless of
how many revocations happen or how much rework needs to be done. They need to be
able to quickly find the accurate history of all the interactions with Print Buyers.
When exception handling for one transaction in the workflow has an impact on other
transactions, composite scenarios arise:
Incomplete workflow, resulting in revoke declare
─ A1 finds out that one box (out of 10 boxes) is still on the transport platform (only
9 boxes were shipped to CA2). In the meanwhile, the declare has been performed
by CA8 (Order Shipper) on behalf of A1: “here are your 10 boxes of books”.
─ The declare has to be revoked (rv[da]), but only part of the execution of Order
Fulfilment is redone (only the shipping of the remaining box).
Failure during workflow, damaging the products of previous transactions
─ When batches of printed letters (T5) are sent to enveloping (T6) and batches are
damaged during T6: execution of T6 has to be put on hold and T5 needs to be
redone.
─ The outcome of T6 (failure for that particular batch, but maybe success for other
batches) is declared towards A1, who decides how to request Print (T5) and Finish
(T6) again, only for the damaged batch and with a high priority, in order not to
keep T6 on hold for too long.
Late detection of issues that are difficult to notice upfront
─ Production and packaging of booklets: after all the booklets have been accepted
from a print (T5) and finishing (T6) quality point of view (no stains, no content
clipped off). When trying to package (T7) them, A7 notices the booklets do not
fit in the boxes, since they are too wide (trimming issue that is easy to overlook).
─ All production transactions that precede T7 have to be redone.
The identified composite cases shall be further investigated, to decide whether im-
provements are needed to better accommodate the PSP way of working.
5
4 Conclusions and Future Work
The need to offer unique products, to differentiate from the competitors, made it man-
datory for PSPs to have a flexible workflow; to achieve this, PSPs adopt print workflow
management software systems, such as PRISMAdirect.
This paper extends the reach of the DEMO methodology and uses its modeling tools
for PSP organizations. During scenario modeling, act-level delegation of responsibili-
ties was needed. In many PSPs, exception handling policies are not well defined, while
the EE theory on revocations is still evolving. The intention is to continue eliciting
policies from the field using the EE concepts and challenge the theory with the findings.
The decision points are essential in a PSP (see Fig. 2). The request and declare acts
are preceded by semi-decision points (meta level acts quit and stop are not depicted).
Fig. 2. Complete transaction pattern highlighting decision points.
Printing, a field that has been perceived as a pure production business for a long
time, has proven to be the source for coordination scenarios, based on the evolution of
the working style (workflow) within PSP organizations.
References
1. Perinforma, A.P.C.: The Essence of Organisation: An Introduction to Enterprise Engineer-
ing. 2nd edn. Sapio Enterprise Engineering (2015)
2. McGrew P., Do You Have a Workflow?, Keypoint Intelligence InfoBlog (Insight from In-
foTrends), http://blog.infotrends.com/?p=21811
3. PODi website, http://www.podi.org/Canon-PRISMAdirect-PODi-Product-Briefing.html
4. Dietz, J.L.G.: The deep structure of business processes. Communications of the ACM - Two
decades of the language-action perspective 49(5), 58–64 (2006)
5. Dietz, J. L. G.: The PSI theory - understanding human collaboration (2017)
6. CSA portal, https://csa.canon.com/online/portal/csa/csa/products/software/softwarede-
tail/software/prismadirect-workflow-management-solution