The DEMO methodology was devised to facilitate organizational change, by providing means to model the essence of an organization. The intention of this paper is to extend the reach of this methodology into the printing industry realm, modeling scenarios of Print Service Provider customers and employees 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 improvement idea emerged for the delegation of responsibilities, while complex exception handling scenarios shall be further investigated.
Organizations nowadays are facing changes more frequently than before, due to
continuously evolving market needs. Professor Jan L.G. Dietz proposes the DEMO
(Design and Engineering Methodology for Organizations) methodology, in the EE
(Enterprise Engineering) discipline [
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
workflow [
Coordination and production acts [
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 typical PSP workflow. More complex scenarios are discussed in section 3, while section 4 reveals conclusions and future work directions. 2
Typical scenarios from a PSP were modeled by means of the DEMO approach [
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-ondelivery 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. cutting, 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 operator (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 shipping, jobs are usually packaged (T7) into containers, e.g. envelopes, boxes.
The trigger concept (Process Model) is useful to model automation of payment request (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).
The transaction pattern coverage offered by PRISMAdirect was assessed, since the
software system had been designed without any knowledge of DEMO. The main
concept in PRISMAdirect [
Scenarios of increasing complexity, involving revocation or delegation, were studied. In the authors’ experience, exception handling cases are the most difficult to model. 3.1
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).
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
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 suggest 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 improvements are needed to better accommodate the PSP way of working.
The need to offer unique products, to differentiate from the competitors, made it mandatory 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 responsibilities 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).
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.