Professional Documents
Culture Documents
I. INTRODUCTION
Effective business processes can bring competitive
advantage for a company and IT systems are a valuable asset in
the information centric processes. IT systems enable process
automation, contain valuable business logic and complex
business rules, support business specialists as process tools,
and enable the storage of the information. The complexity of
the IT systems has increased and one business process may
utilize several software systems, components, SOA services,
and integrations. Furthermore, the amount of stakeholders is
often very high as the business process may flow over several
organization units, have external or outsourced parts, and can
be closely connected with customers processes.
Process models have been a tool for developing business
during the past decades. Processes have been developed from
different perspectives, for example optimizing process work,
removing waste based on lean principles, developing
organization practices to meet quality standards, automating
978-1-4673-7340-1/15 $31.00 2015 IEEE
DOI 10.1109/CBI.2015.20
242
Project
documentation
review
Validation
workshops
243
TABLE II.
Project
Project A Insurance
process
automation and
project D developing
Insurance
processes further
Project B
Pension
estimation
process
Project E
Renewal
of
financial
processes
Projects G-P
D. Validity Evaluation
Threats to validity were analyzed based on the framework
by Runeson et al. [18]. The authors of the paper are employees
of the case study organization, which is both a strength and a
possible threat to the validity of the results. Based on the
practical experience of the case study organizations RE
process, BDD method implementation and projects studied, the
authors have background information and the researchers had
full access to all necessary project documentation.
As a threat, the researchers' own experience may have
affected the interpretation of the results. To avoid construct
validity threats, validation workshops where the practitioners
of the case study company reviewed the findings iteratively
were organized. This study is based on experiences of a single
organization and does not give conclusive results of
244
Figure 1.
First, the importance of strategic development goals was
emphasized by the interviewees. Strategic development goals
were needed to steer to-be process modeling and requirements
definition, for example expected automation level, customer
value and benefits and development costs. In four studied
projects, development goals were defined based on the analysis
of the process capabilities, which brought the focus into all the
assets related to process (IT systems, human resources and
knowledge of individuals, process instructions, etc.). Second
perspective identified was the organizational approach.
Business processes flow over several organizational units and
transformation of the business process often required
development or organizational capabilities, roles and
responsibilities, and sometimes outsourcing decisions. The
third perspective identified was the business process approach,
including business process workflows, business rules and logic
needed. The fourth perspective identified was the system level
including descriptions of how the process is performed in the
IT systems, services, and integrations including also manual
tasks.
As-is process modeling was needed to fully understand the
current end-to-end processes functionality, software systems
used and current state challenges. Both system and business
specialists knew deeply parts of the process, but end-to-end
process knowledge was rare. Though understanding of current
state as-is processes is important, most focus and resources
should be spent on to-be modeling.
Enterprise process modeling is a comprehensive approach
including all processes of the company. If comprehensive
current state process modeling exists in the company,
development projects may utilize the documentation as a
starting point. The process hierarchy was identified as a useful
tool for defining the development project scope based on the
business processes and establishing common vocabulary
between the stakeholders. The process hierarchy was also used
in the acceptance testing to set the focus of the testing efforts to
end-to-end business processes.
Modeling a complex business process comprehensively at
different hierarchical levels required extensive effort. High
level process models and the process hierarchy were useful
from the management point of view in the organizational
perspective. Business specialists were interested in business
process and business logic mainly from the functional and
behavioral perspectives. Specific system level process models
were often needed by the technical people from the
informational perspective. Most of the practitioners would have
preferred a single model for business and system level
processes.
Business process modeling including process hierarchy and
245
Process
hierarchy
/
process mapping
Development
goal
setting
based on process
capabilities
Analysis model /
business process
model
Design model /
system
level
model
Solution
planning
and
analysis (SOA
services,
software
products etc.)
Modeling tools
and
round
tripping between
the models
Modeling
process
supported
several
integrated
systems
by
246
TABLE IV.
TECHNIQUES
Combining
use cases to
process models
Business
use
cases vs. system
use cases
Business rules
Reusable
business rules
Development
goals
Functional
requirements
Non-functional
requirements
Architecture
models
and
guidelines
User stories
Concepts
Examples
Lessons learned
Process tasks were further specified with use cases
to define business and system logic steps,
alternatives, handling rules and exceptions. When
use cases are modeled based on process tasks, the
modeling may not be optimal from UML modeling
perspective. However, combining two approaches
brought value from the business modeling
perspective.
In project A and D, use cases defined combined
both business and system level aspects. Business
specialists preferred detailed system specific use
cases over separate high level business use cases.
Business level use cases were defined in project B
based on analysis level process maps, but deriving
system level use cases during the specifications
phase with the software supplier was challenging.
Business rules were used to define requirements
related to business logic. Rules provide
understandable documentation for business people
and formally define business logic for system
development purposes.
One business rule may be used in different process
phase or use case. Business rules were defined in
many projects as a part of use case documentation.
If the same rule was utilized in many use cases,
separate business rule documentation was utilized.
The importance of goals to steer the requirements
definition and project work in general was
emphasized. The studied projects had initial high
level goals. In addition to top-down derived goals
from the management, also unwritten goals from
different stakeholders can be recognized (derived
bottom-up).
In addition to automated processes, users use the
functionalities of the system manually. Customer
service, for example, is often based on performing
several tasks reviewing and updating customer
information. In addition to process modeling,
functional requirements (system shall phrases)
were used to supplement process models.
Process modeling did not cover all non-functional
requirements such as reliability, maintainability,
security, usability and fault tolerance. Company
had a set of frequently needed non-functional
requirements to be used as a starting point of
project requirements definition. Process modeling
may be used to collect requirements, but additional
requirements documentation was needed.
Process models were seen as a tool for connecting
business
and
architecture
development.
Architecture guidelines have brought vital
requirements related to services, software products,
integrations and information.
Also enterprise
architecture guidelines and enterprise IT
infrastructure may bring limitations to solutions.
Architecture guidelines were needed in the
procurement for the suppliers to deliver comparable
bids.
User stories were considered as a useful tool for
modeling stakeholder requirements. Connecting the
user role and benefits expected to the requirements
has been useful.
User interface concepts and product concepts, for
example, have been utilized to develop and
visualize business ideas.
Examples of specialties of the business area have
been useful to make difficult functionalities
understandable.
247
VI. CONCLUSIONS
Based on the experiences received, we recommend using
business process modeling as a visual tool for combining
business and IT development. If comprehensive large-scale
hierarchical process modeling is not possible or feasible,
defining a process hierarchy and modeling a selection of the
most important business processes increases common
understanding of end-to-end business processes and adds value.
Also in the complex integrated environment, process modeling
may be a useful tool for modeling how the business process is
actually performed at the system level. In addition to process
modeling, other modeling of the requirements was also needed.
The importance of strategic development goals to steer the
process modeling and requirements definition was emphasized.
Combining process modeling to use cases and collecting
248
[4]
[5]
[9]
REFERENCES
T. Panagacos, The Ultimate Guide to Business Process
Management: Everything You Need to Know and How to Apply
It to Your Organization, CreateSpace Independent Publishing
Platform, 2012.
[8]
[3]
ACKNOWLEDGMENT
[7]
[2]
[1]
[6]
249