Applying YAWL for the Automated Execution
of Film Production Processes
Chun Ouyang, Marcello La Rosa, Guy Redding, and Jessica Prestedge
BPM Group, Faculty of Information Technology,
Queensland University of Technology,
GPO Box 2434, Brisbane QLD 4001, Australia
{c.ouyang,m.larosa,g.redding,j.prestedge}@qut.edu.au
1
Introduction
The Business Process Management (BPM) Group at the Queensland University
of Technology (QUT) is involved in a project [3] that aims at applying BPM
to the Creative Industries. As part of QUT’s Centre of Excellence for Creative
Industries and Innovation, the project has progressed through close cooperation
between QUT’s BPM Group and the Australian Film, Television and Radio
School (AFTRS). It proposes to apply the general principles, methods and tools
of BPM into selected areas of the creative industries such as the Screen Business. The Screen Business comprises all creative and business related aspects and
processes of film, television and new media content, from concept, to production
and distribution. A value chain model for the screen business has been developed [9], which consists of four stages: Development, Pre-Production, Production,
and Post-Production.
As part of the project, we used the open source workflow system YAWL
(Yet Another Workflow Language) [1] to automate the execution of the Film
Production Process. YAWL offers comprehensive support for workflow patterns,
analysis at build time, persistence, automated form generation, and is based on
XML technologies. Its service-oriented architecture facilitates the development
of sophisticated extensions that enable developers to tailor a YAWL-based workflow system to the requirements of a particular setting, e.g. the Screen Business
Production.
The term “Film Production Process” refers to the process within the Production stage of the Screen Business value chain for film-making. In most cases
the Production stage is the most expensive one, as during this stage the movie
is actually created and shot. The shooting procedure is carried out on a daily
basis, and the production process covers the entire shooting period from the first
shooting day to the last shooting day. During each day, a number of documents
need to be filled, updated or generated on set, e.g., to record the daily shooting progress, to update the next day’s shooting schedule, to calculate the staff
worked hours and to set up the payments. Currently, a daily shooting procedure
is manually operated, where processing and coordinating these daily documents
is very time-consuming and error-prone, and in the worst case it may even cause
delay to the next day’s shooting schedule. Such a process can therefore benefit
from the application of a workflow system to optimize the process execution as
well as to automate the daily document processing, which may further reduce
the cost of the film production.
When applying YAWL to the Film Production Process, special attention
needs to be paid to the creative and highly agile nature of the process and how
it may be appropriately modeled. One goal is to automate the process without
affecting nor limiting the creativity. This can be done by identifying creative
tasks (e.g., updating the film script) as part of the overall process. On the one
hand, a workflow system such as YAWL can be used to improve and automate
the non-creative parts of the process, and as a result the film production team can
spend more time on the creative tasks thus increasing the quality of creativity.
On the other hand, it can open the opportunity to support creative tasks with
appropriate techniques, methods and software tools.
Apart from its creative nature, a Film Production Process is also characterized with high demands for flexibility. For example, the process may be deployed
across a central production office, where reports are produced and communicated, and a mobile unit for film shooting, as shown in Fig. 1. Unlike traditional business processes where the network connectivity is always ensured, the
availability of network connection between the production office and the mobile shooting unit highly relies on the remote location of the unit (e.g., the unit
may be located in a rural area without any network coverage). Hence, the traditional workflow model which requires network connection throughout the entire
business process, needs to be revised so that the resulting model is capable to
support the off-line execution of parts of the process.
Wireless / Satellite
Transceiver
Wireless / Satellite
Transceiver
YAWL
Server
VPN over the Internet
Bluetooth
Printer
YAWL
Database
PDA
Laptop
Production Office
Mobile Unit
Fig. 1. A typical hardware infrastructure for the Film Production Process.
During the implementation of the Film Production Process, we developed extensions to the YAWL system to support this particular application. YAWL applies
the XForms [4] technology to generate user interfaces. In particular, the Chiba
XForms processor [7] is used to create XForms automatically and to gather and
validate input from users dynamically. However, since Chiba only supports limited form formatting, we opted to implement customized user forms in JSP [8],
so that the forms could match the formatting style of professional film production documents. The generated JSP forms have been integrated to YAWL as an
alternative user interface to XForms.
Next, we briefly describe the YAWL process model from design to implementation. The YAWL System, as well as a set of screenshots of the running process
are available at [2].
2
2
System Description
The Film Production Process was implemented as a YAWL process model capturing the control-flow, data, and the human resources involved in a film production. The model, depicted in Fig. 2, is based on a loop structure, where each
loop instance captures a daily shooting procedure and the number of instances
executed captures the number of the shooting days carried out. When a shooting
day starts, four tasks are executed in parallel to fill out respectively the Continuity Report, the Sound Sheet, the Camera Sheet, and the Assistant Director’s
(AD) Report. For each of these tasks it is possible to submit a partially filled
document before completion, which can be seen on-the-fly by the central production office. This feature is usually required to monitor the shooting progress.
Once the four tasks are all completed, a Daily Progress Report (DPR) is automatically generated as a collection of key information from the above four
documents. Next, the process splits into two parallel paths. The lower path is
used for DPR distribution, where the DPR is first sent to the Producer and
then forwarded to the Executive Producer and the Completion Guarantor. The
upper path is used for the generation of the Call Sheet, which contains the most
up-to-date schedule for the next shooting day. After updating the Schedule, the
Shotlist, the Storyboard and the Script, the Call Sheet can be filled out. Once
the Call Sheet is completed, it is distributed to all cast and crew. This completes
the daily shooting procedure.
Fig. 2. The YAWL model of a film production process.
The tasks between the start of a daily shooting procedure and the automatic
generation of the DPR are mainly performed on set (i.e., where the mobile unit is
located), while the tasks between the generation of the DPR and the distribution
of the Call Sheet are mainly performed at the production office. If no network
connection exists between the production office and the mobile unit, the original
process model needs to be split into two models – one executed at the mobile unit,
3
the other at the production office. These two processes are indeed dependent on
each other, as the first produces a DPR an output and needs a Call Sheet as
input, whilst the other produces a Call Sheet as output and needs a DPR as
input. Exchanging such documents between the two processes would need to be
supported by other means, e.g., a courier.
XML Schema [5] was used to represent the data documents of the process.
The assignment of human resources to process tasks is supported by the YAWL
Editor (at deign-time) and by the YAWL Administrative Tool (at run-time).
We used these tools to assign production crew roles to each task, e.g. the role
Sound Editor has been assigned the task “Fill Out Sound Sheet”. Due to space
limitations, we do not show the details of the data and resources implementation.
Professional-looking forms were created in HTML, and then wrapped in JSP
to capture the logic behind the data representation. On each JSP form we implemented the following features: “Load” – to open a data file into the JSP form,
“Save” – to store the input data to the local system (e.g. the laptop of a crew
member), and “Submit” – to submit the input data back to the YAWL engine
that runs the process. For persistency purposes, the submitted form is also saved
into the server where the engine is installed. We used JAXB [6] to handle the
manipulation of XML files in Java between JSP forms and YAWL.
To validate the Film Production Process and the YAWL system from a practical perspective, we will deploy the process in the production of a real feature
movie with a Sydney’s film company. The movie will be shot by two mobile units
in rural areas of New South Wales (no network coverage), while the production
office will be set up in town.
About the demonstration. The demonstration will show the YAWL model
for the Film Production Process, with a focus on the process control-flow and
on the data and resources involved. A running instance of the process model will
also be shown, using sample documents provided by the AFTRS.
References
1. W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet Another Workflow
Language. Information Systems, 30(4): 245–275, 2004.
2. The YAWL System @ SourceForge. http://sourceforge.net/projects/yawl.
3. QUT Research Project: BPM for the Creative Industries. www.screenbusiness.org
4. XForms 1.0 (SE). W3C Recommendation, 14 March 2006. www.w3.org/TR/xforms.
5. XML Schema 1.1 Part 0: Primer (SE). W3C Recommendation, 28 October 2004.
http://www.w3.org/TR/xmlschema-0.
6. Java Architecture for XML Binding (JAXB) 2.1.3. Sun Microsystems. 13 April,
2007. https://jaxb.dev.java.net.
7. Chiba Core 1.3.0 (4 December 2006) and Chiba Web 2.0.0 (29 March, 2007). Chiba.
http://chiba.sourceforge.net.
8. JavaServer Pages Technology (JSP). Sun Microsystems. 10 May 2006. http://
java.sun.com/products/jsp.
9. S. Seidel, M. Rosemann, A.H.M. ter Hofstede, and L. Bradford. Developing a Business Process Reference Model for the Screen Businss – A Design Science Research
Case Study. In Proceedings of the 17th ACIS, Adelaide, Australia, 2006.
4