# Improving PA Business Processes through Modeling, Analysis, and Reengineering

Damiano Falcioni, Andrea Polini, Alberto Polzonetti, Barbara Re

► To cite this version:

Damiano Falcioni, Andrea Polini, Alberto Polzonetti, Barbara Re. Improving PA Business Processes through Modeling, Analysis, and Reengineering. 11th International Conference on Electronic Government (EGOV), Sep 2012, Kristiansand, Norway. pp.78-89, 10.1007/978-3-642-33489-4_7 hal-01543595

HAL Id: hal-01543595

https://inria.hal.science/hal-01543595v1

Submitted on 21 Jun 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Improving PA Business Processes through Modeling, Analysis, and Reengineering

Damiano Falcioni, Andrea Polini, Alberto Polzonetti, Barbara Re

Computer Science Division, School of Science and Technologies
University of Camerino, 62032 - Camerino (MC), ITALY
{name.surname}@unicam.it

**Abstract.** Too often e-government services are derived from “old style” intra- and inter-administration Business Processes without taking into account the potentiality of adopted technologies.

In this paper we present our experience in Inter-organizational Business Processes modeling, analysis and reengineering in order to make them more effective and efficient. We used semi-formal notations to model three complex services. To do that we directly involved domain experts and civil servants. Thanks to the resulting models, we identified several pitfalls and opportunities for improvements. As a result we were able both to derive ameliorated versions for the analysed services, and to identify common “bad habits” in the specification, permitting to define a general quality framework for services improvement.

## 1 Introduction

Since the 90s, the Public Administration (PA) has changed profoundly thanks to the introduction of Information and Communication Technology (ICT) delivered by the investments made by PA for the development of the digital society. PA services are today widely available via ICT based solutions. Nevertheless poorly structured organizational Business Processes (BPs) result in low quality PAs outcomes, inefficiency and ineffectiveness.

Initially ICT solutions have been introduced within single offices, successively the challenge became the possibility of permitting the direct interoperation of different software infrastructure, so to have an integrated PA. Nevertheless such integration is still on-going and many issues still need to be solved. In particular the integration initially referred to the communication infrastructure and now the effort is particularly interesting with respect to the application level. At this level BP specification is the main instrument to describe how related administration could effectively cooperate. Nevertheless BP specifications are extremely complex and careful evaluation should be undertaken to assess their effectiveness and efficiency. For instance too often specified BPs strictly reflect paper based interactions, and do not take into account possible opportunities that ICT solutions could provide.

In this paper, we report on our experience in BP modeling, analysis and re-engineering. In particular we considered three BPs of various complexity. Together with domain experts we modeled them using BPMN 2.0 The notation
resulted to be highly intuitive so to permit the easy exchange of information
and idea between technology and domain experts. Thanks to the notation we
were able to identify common pitfalls and to suggest solutions for re-engineering
processes.

The rest of the paper is organized as follows. The next section presents related works, whereas Section 3 introduces basic concepts in BP modeling. In Section 4 we describe the various case studies and then in Section 5 we report the derived quality framework. Finally, before drawing some conclusions and opportunities for future work in Section 7, we describe the re-engineering phase.

## 2 Related Work

Modelling and re-engineering PA BPs are quite complex tasks. It is well known that between 60re-engineering is considered a mean of rightsizing government. At the same time it is a possibility for information systems redesign [1]. Generally speaking several approaches can be found in the literature regarding the re-engineering of BPs for improving government. This aspect has been discussed in general by the US federal government and the US Department of Defense in [2] and with respect to specific context of use, e.g. department organization in [3], and electronic voting in [4]. In literature there are also example of more structured approaches. In particular, in [5] the authors discuss a methodology to support an integrated environment that can be used for better law and process re-design by performing formal analysis on the BP specification. These approaches are different from what we propose here since they do not particularly face the challenges of complex inter-organizational BP, where communication and coordination play a fundamental role.

## 3 Business Process Modeling

Technically services are modelled and implemented using notations and tools based on the BP concept. "A BP is a collection of related and structured activities undertaken by one or more organizations in order to pursue some particular goal. Within an organization a BP results in the provisioning of services or in the production of goods for internal or external stakeholders" [6]. In addition to the BP concept collaborative BP represents an issue in order to reach the suitable point of view able to represent the right abstraction level [7]. Recent works show that BP modelling has been identified as a fundamental phase in Business Process Modeling (BPM). The quality of BPs resulting from the BP modelling phase is critical for the success of an organization. Its importance exponentially grows in order to support inter-organization process and related service delivery. Different classes of languages to express BPs have been investigated and defined. There are general purpose and standardized languages, such as the BPMN 2.0 [8] or the Event-Driven Process Chain [9] and many others. There are also more academic related languages, being the Yet Another Work-flow Language [10], based on Petri Nets, the most prominent example.
In our work we refer to BPMN 2.0 [8] an Object Management Group (OMG) standard. This is certainly the most used language in practical context also given its intuitive graphical notation. We mainly use collaboration and conversation diagrams in order to have a complete representation both of internal process as well as of the message exchange structure. In particular, conversation diagrams are suitable to models message exchange between participants that together achieve a common goal.

# 4 Case Studies

The work we present relies on three real case studies concerning PA provided services. All of them are examples of inter-organizations BP with several inter-actions between PAs. In particular, the considered services are:

- **Family reunion** - this is a service available for people legally residing in Italy which can apply on behalf of their relatives (spouse, depending parents, children less than 18 years old) for the purpose of family reunion and only after having provided evidence of their status with respect to “sufficient” incomes and a permanent address.

- **Grant citizenship** - this is a service used to ask for Italian citizenship by a foreigner or stateless person who has married to an Italian citizen or who is continuously residing in Italy since not less than three years.

- **Bouncers registration** - this is a service used to register bouncers in order to carry out their activity within public places.

The first and the second service require complex and inter-organizational BPs and they are in place for several years now, therefore can be considered deeply tested. To give a quantitative indication in 2010 the Prefecture of Ancona (the capital city of Marche Region, in Italy) received 469 applications for family reunion and 760 applications for granting citizenship. For what concerns the bouncers registration service, even if it presents a simple scenario, we choose it because its deployment is still on-going. We had the opportunity then to intervene and contribute to its development. In the following of this section we illustrate the different processes, and we provide some data useful to have an idea of their complexity. For each process we developed a BPMN 2.0 specification in the form of a collaboration diagram that we do not report here given its graphical complexity and needed space<fnref n="1" />. In the following we provide a general description of each service, as they have been initially described by domain experts in the form of scenario specifications.

<footnote n="1">¹ Source of process models can be found in: http://ueg.blog.cs.unicam.it/?p=414</footnote>
**Family Reunion.** The family reunion service is based on the principle of "fam-
ily unity". In 1986 the first immigration law was promulgated in Italy as a result
of the large number of applications submitted by foreigners in order to be reunite
with their relatives. The Law went through several changes before the current
version. The latest changes have been made by the legislative decree of 3 October
2008, n. 160 and then by Law 15 July 2009 n. 94 named "Measures for public
safety".

Several participants are involved in the delivery of this service. The beneficia-
ries are both the foreigner, which applies for family reunion (or a patronage that
acts on his/her behalf), and the family members to be reunited. The different
PAs involved in the service delivery are:

- The Prefecture is the main driver of the process, on behalf of the Department for Civil Liberties and Immigration of the Ministry of Interior according to the geographical location of the applicant.

- The Police headquarters is in charge of public security controls and they give opinions on the feasibility of the application.

- The Italian authorities abroad (consulate or embassy) is responsible for ver-
ifying the subjective requirements.

- The Ministry of Foreign Affairs communicates the result of the procedure to the Italian authorities located in the state of the requesting beneficiary.

- The Ministry of Finance is in charge of releasing the fiscal code for the incoming relative.

To support the process the Department for Civil Liberties and Immigration of the Ministry of Interior developed and deployed a “one stop shop” service for immigration, named SPI. All the 106 Italian prefectures can access and use the system, which permits to the beneficiaries to electronically apply and verify the status of the request, via a secured access. The main steps of the BP supported by the SPI are described in the following.

1. The BP starts with a reunion application done by beneficiaries living in Italy using a downloadable software client freely available after registration.

2. The application is managed by the SPI and assigned to a prefecture that asks, for public safety constraints, to the Police Headquarters and than invites the beneficiary to the Prefecture in order to check her/his status. Both the opinions from police and Prefecture may be cause of application rejection. Otherwise in case of acceptance the Ministry of Foreign Affairs provides the go-ahead (“nulla osta”).

3. After the release of the “nulla-osta” the relative that has to be reunited goes to the Italian consulate or embassy in its country, and proving some specific requirements asks for VISA in order to come to Italy.

4. Once in Italy the foreigner must go (within 8 days) to the Prefecture in order to register his/her arrival in Italy, to receive the fiscal code, thanks to the interaction with the Ministry of Finance, and to finally obtain the residence permit.
**Grant Citizenship.** Grant citizenship is a service to be used by foreigners and stateless persons to ask for Italian citizenship. The first regulation is the Law of 13 June 1912, n. 555 implementing the concept of family relationships assigning a position of absolute pre-eminence of the husband respect to his wife, at that time commonly recognized. After several law evolutions currently the law n. 91 5/2/1992 declares as main principle that of “ius sanguinis”. At the same time, taking into account the strong migration occurred in our country, people can obtain Italian citizenship for marriage or after long residence.

Several participants are involved in such service. The beneficiary is the for-
eigner which applies for Italian citizenship and the participants are the different
Public Administrations involved in the service delivery as following:

- The Prefecture, on behalf of the Department for Civil Liberties and Immi-gration of the Ministry of Interior according to the geographical location of the request, is the main actor and drives the process, receiving the request, checking the requirements and giving the opinion;

- The Ministry of Interior receives electronically the request and the docu-
  mentation, checks them, valuates the instance and took the final decision;

- The Municipality officiates to the new citizen sworn;

- The Ministry of Foreign Affair, Police headquarters, Ministry of Justice and public security offices such as Information Agency and External Security, Information Agency and Internal Security, give their opinions on the appli-cation.

In order to support the process the Department for Civil Liberties and Im-
migration of the Ministry of Interior decided to develop an electronic system,
named SICITT, suitable to manage requests and documentations for granting
citizenship. SICITT satisfies the needs of the Ministry of Interior to commu-
nicate with other offices involved in the process of grant citizenship mainly to
obtain the opinions. It is in use in all the Prefectures and in almost every police-
headquarter. The main steps of the BP supported by SICITT are described in
the following.

1. The process starts with a request done by the foreigner by ordinary mail or delivered by hand to the Prefecture. The SICITT foresees that an employee uploads the request.

2. Document verification is the next step according to the following conditions.

a) The prefecture asks to complete the documentation in case some doc-
ument is missing. Then the applicant has to produce and deliver the
required documents to the Prefecture, otherwise the citizenship office
begins the procedure for instance rejection.

b) The prefecture notifies the begin of the rejected procedure if some re-
quirement is not satisfied. In 30 days the applicant has to solve such
condition otherwise the request will be classified as inadmissible.

3. On the other side when the documentation is complete and all the require-
ments are satisfied.
- The request inserted in SICITT becomes visible to the police-headquarters that checks the absence of impediments, and then expresses an opinion. If the Prefecture does not receive the police-headquarters opinion in 6 months, it solicits the office.

- Only after receiving the opinion of the police-headquarters, the Prefecture sends its opinion to the Ministry of Interior. Contemporary to the receiving of the application to the Ministry of Interior, the SICITT automatically sends a request of information to other involved offices.

- Only after receiving all the opinions, the Ministry of Interior verifies the instance and it can decide to: (i) ask for an integration of the documents; (ii) start the procedure for the rejection of the instance; and (iii) confirm grant citizenship. Any final decision is sent to the Prefecture that is in charge to notify the applicant about the decision.

- In case of confirmation, the Prefecture asks to the municipality to call the applicant for the oath. Only after the communication that the applicant has sworn, the process is closed.

**Bouncier Registration.** The bouncier is a person employed by a cinema, recreation ground, nightclub or similar establishment to prevent troublemakers from entering or to reject them from the premises. In Italy, a national registry has been created according to the Ministry of Interior decree of 6 October 2009.

Several participants are involved in the provisioning of such a service. The beneficiaries are the managers of public place or vigilance institute that do the request, and the bouncier who will be registered in the list. The participants are the different PAs involved in the service delivery. In particular, we refer to the following:

- The Prefecture, on behalf of the Department of Public Security of the Ministry of Interior according to the geographical location of the place, has to receive the request and decides for granting or rejecting decree;

- The Police headquarters and several police departments such as Police anti-crime, General Investigation division and Special Operation (Italian acronym DIGOS) that give their opinions.

To guarantee the process the Department of Public Security of the Ministry of Interior is developing an application, named BTF to electronically manage the requests of inscription in the registry. Up to now the BTF is going to be used by all the Prefectures and the police-headquarters, but it is expected that in a second phase it will support a fully interactive service. The main steps of the BP supported by BTF are described in the following.

1. The process starts with a request delivered by hand or by ordinary mail, from a manager of a public place or of a vigilance institute, to the Prefecture in charge to manage it. The request is successively manually uploaded into the BTF by an employee.

2. The Prefecture proceeds with the documents verification, it may happen that the documentation is incomplete. In this case it asks for integration to the applicant.
3. When the documentation is complete, the Prefecture analyzes it and then waits for the opinion from the police-headquarters that has to come within two weeks. If the Prefecture does not receive the opinion, it has to solicit the police-headquarters.

4. Before giving the opinion, the police-headquarters asks to other police offices, Police anti-crime and DIGOS, for receiving more information about the bouncers.

5. After receiving all the opinions from all the police-headquarters, the Prefecture decides the instance. If it is positive the inscription in the list of bouncers is authorized, otherwise the request is rejected.

*Case Studies modeling with BPMN 2.0.* The scenarios informally described above are made complex by the many possible exceptions which can occur after their activation. It was quite clear that a natural based language specification would have shortly ended in chaotic descriptions. In cooperation with the domain experts we started to model each BP using BPMN 2.0. This notation resulted enough intuitive for domain experts and with our help we managed to derive diagrams for each BP. The first step has been the definition of involved actors and of the communications intervening among them. This led to the definition of the BPMN 2.0 communication diagrams for each case scenario.

Successively we iterated several times in order to define the collaboration diagram for each service. As said, given space constraints, we do not report the diagrams here, nevertheless some number can roughly provide an idea of the complexity of such BPs. For the different classes of graphical constructs provided by BPMN 2.0, Table 2 reports the number of instances which are included in the different BPs for each different class of constructs. It is worth mentioning that each message exchange typically introduces complex relationships among different actors (pools), leading to intricate workflow scenarios. Moreover unnecessary synchronizations, caused by message exchange, tend to reduce the degree of parallelism possibly leading to BPs lasting longer than necessary.

<table><caption>**Table 1.** Complexity of services under study.</caption><thead><tr><td></td><td>Pools</td><td>Activities</td><td>Events</td><td>Decision Points</td><td>Message Flow</td></tr></thead><tbody><tr><td>Family Reunion</td><td>8</td><td>57</td><td>74</td><td>29</td><td>36</td></tr><tr><td>Grant Citizenship</td><td>11</td><td>75</td><td>93</td><td>42</td><td>62</td></tr><tr><td>Buncher Registration</td><td>6</td><td>16</td><td>24</td><td>14</td><td>17</td></tr></tbody></table>

# 5 A Framework for Analysis of BPs for the PA

In this section we report our findings on possible improvements for BP related to PA service delivery. Having in mind that e-government service provisioning is
the result of a close collaboration among different PA, a fundamental aspect to consider, improving quality of service, is the overall vision of the process. The optimization of the whole service delivery can be reached if and only if all intra-administration processes implemented by different PA are optimized. A delay or a lack in one organization has a negative impact on the overall quality perceived by the user. This aspect has to deal with the need to clarify, from the very beginning, which are the participants and the activities involved in the process, and how they can cooperate and share or exchange information. It is important to provide an overall view on the service in term of inter-organization processes where each view is implemented in the different PAs.

In our work we iterated many times among modeling and analysis activities. During analysis phases we tried to identify possible pitfalls leading to low quality or unjustifiably expensive BPs. Each identified issue was recorded and we successively tried to generalize and classify all of them in order to make easier their verification with respect to any modeled process. The result is a sort of quality framework that can be used to easily assess and improve BPs for the PA. Identified critical aspects can be classified in three main areas as follows.

**Involvement of all participants in the modeled BP and resulting software system.**

**R1:** We discovered that sometimes a participant was included in the list of involved action but no precise task was clearly assigned to it. Moreover all the involved PA has to be integrated as much as possible in the system supporting the BP. This means that when possible all the activities have to be performed on-line and all the communications between PA have to be done electronically through the IT system.

**Back offices integration and optimization.**

**R2:** There must be just necessary activities and when possible those with the same input/output without process status change should be merged. We can evaluate the activities considering the value that they add to the BP. It may be useful to identify the value according functionality that has to be provided (i.e. in activities with the delivery of documentations, the values add is the document delivered, while for verification activities the value is identified as a check).

**R3:** Communication between PAs should be direct without intermediate steps. We refer to the case of a "word of mouth" where a participant receives a communication and immediately after the reception sends it to another participant without any kind of transformation of the received information.

**R4:** Document management has to be a core issue in the PA back office. Documents mainly result from the execution of a task and can represent its input and/or output. A document may be produced in an activity during the investigation phase, or it may concern a final decision. In both cases, it should be fully integrated in the BP.

**R5:** Documents, and more generally data, already available by one or more PA should be shared avoiding continuous requests for data to the citizens. All the documents produced during the process have to be recoverable.
- Communication with the users.

R6: Communications between PAs and users have to be exchanged electronically. To reach all the population and according to the problem of digital divide, it must be possible to communicate with the PA through several channels, for example mobile phones and digital television, in order to allow everyone to use the service.

6 BPs Re-engineering

In this section we report the interventions we have done on the various BPs
in order to improve their overall quality. For each modification we report here
a reference to the specific guidelines presented in the previous section, and to
which the modification is related.

Family Reunion

[R1] - We noticed that many communications among the different offices of in-
volved PAs were done outside the SPI system mainly using fax, even though
the data exchange could have happened within the system. The re-engineering
aimed at reducing such type of communications stressing the importance of PAs
effective collaboration;

[R2] - The BP presents many “null added-value” activities, in particular (i) in managing the expulsion all the communications goes to the SPI and that task forward to the office in charge to complete it, (ii) the SPI has to receive the pa- per based confirmation from the Foreign Affairs before delivering the nulla-osta and (iii) the Prefecture delivers the nulla-osta at home to the applicant after the release. In such cases we propose the following modifications: (i) the expulsion decision is managed between the offices involved to solve the problem, (ii) the one stop-shops releases the nulla-osta after on-line check of Foreign Affair, and (iii) the Prefecture delivers the nulla-osta when the familiar to be reunite comes to Italy and visit the Prefecture.

[R2] - With respect to merge activities in the process version “as-is”, the ap-
plicant fills and sends the instance after he/she is contacted by the Prefecture
for delivering the documentation. This results as an on-line delivery of request.
Invitation is limited to users presenting incomplete documentation.

[R5] - The introduction of the electronic transmission of the instance per se
does not reduce the number of people visiting the Prefecture offices. In order
to complete the application the beneficiary has to personally deliver the docu-
ments necessary to the service. The main advantage of such transmission refers
to the automatic management of agenda to schedule appointments, avoiding
long queues. We believe that the introduction of legally valid digital documents
should be a real advantage in term of office efficiency.

[R5] - The submission of the request requires a complex sequence of operations that seems to discourage independent and direct submission by the applicant and in most of the cases the applicant asks for support to a patronage qualified to submit the request. We also noticed that application forms and documents of
instructions are written only in Italian. This increases the fear of making mis-
takes in the compilation compromising the successful outcome of the practice.
To make easier the interaction with the users, in the “to-be” process the instance
submission is done by a web application in both Italian and English, rather than
with the intricate downloadable client.

[R6] - Another important issue refers to the many requests done by the admin-
istration with respect to information that they already have, or can easily obtain
by other PAs. To analyse this point we refer to the “nulla-osta” that the famil-
iar to be reunited must present to the Italian consulate or embassy in his/her
country. The Prefecture records the emission of the nulla-osta in the system so,
the Italian authorities abroad may easily check on-line the emission of the doc-
ument. In such a way the delivery of the permission is avoided and workload for
the Prefecture is reduced. It has not anymore to call and receives the applicant
for delivering the original permission for the subsequently presentation to the
Italian authority abroad.

Grant Citizenship

[R1] - The investigation activities done by the Prefecture are mainly carried on outside of the SICITT system. The re-engineering aimed at introducing the management of such activities directly within the SICITT. In this context, an observation is made on the stage of preliminary investigation conducted by the Prefecture, and then on communications between the Prefecture and the applicant. The procedure provides the ability to produce templates to create documents, but the function is not widely used. Some prefectures prefer to use local applications for easier creation of documents and to ensure the automatic conformance to the electronic protocol. Other Prefectures in the management of the investigation proceed manually using traditional document editors. In the “to-be” version the idea is to foster integration and than standardization of the Prefectures back office.

[R1] - With respect to the integration of the different participants in the SICITT system we considered the need to introduce municipalities connections in order to implement a direct channel with the Prefecture and than with the same objective also between Prefecture and the Ministry of Interior. In the process version “as-is” the lack of connection between municipality and Prefecture leads to an exchange of information using ordinary mail. We also highlight that the exchange of information between Ministry of Interior and municipalities could be direct without involving the prefecture so to reduce its workload.

[R2] - Regarding the elimination of “null added-value” activities, instead of con-
tinuously transmitting the decree from the Prefecture to the municipality, and
thanks to the sharing capability, the re-engineering establishes that the munici-
palities can retrieve and analyze the decree directly using the SICITT.

[R5] - In term of communication with the users the novel process support users
integration in SICITT or e-mail based interactions rather than ordinary mail.
However, at this level we recognize that some document has to be delivered in
original version so the automation cannot be implemented.
## Bouncers Registration.

[R1] - Regarding the full involvement of the parties all the police offices have been included in the BTF. This is particularly relevant for communications between police-headquarters and all the other police-offices, in relation to give opinions on a specific instance, and at the same time for rejection interaction from Prefecture to police-headquarters. Up to now some documents are managed in the back office, for example integration request of documentation or solicitation to the police-headquarters. This lacks a partial integration of the back office activities inside the BTF that compromises the quality of the process. The communications between the Prefecture and the applicant should be automated.

[R2] - The Prefecture cannot declare the rejection of the request until the police-headquarters have not given their opinion. This causes a workload for the police-headquarters that must carry on the check activities even when the Prefecture has already decided to reject. A "lazy" approach, in which the opinion of the police headquarters is requested only in case of a positive evaluation from the Prefecture has been introduced in the process.

[R5] - The process version "to-be" supports direct users integration in the BTF not forgetting to include security aspects. The modification we described above

<table><caption>**Table 2.** Characterization of “to-be” process specifications</caption><thead><tr><th></th><th>Pools</th><th>Activities</th><th>Events</th><th>Decision Points</th><th>Message Flow</th></tr></thead><tbody><tr><td>Family Reunion</td><td>7 (8)</td><td>53 (57)</td><td>54 (74)</td><td>24 (29)</td><td>29 (36)</td></tr><tr><td>Grant Citizenship</td><td>11 (11)</td><td>64 (75)</td><td>79 (93)</td><td>30 (42)</td><td>51 (62)</td></tr><tr><td>Buncher Registration</td><td>6 (6)</td><td>19 (16)</td><td>28 (24)</td><td>16 (14)</td><td>16 (17)</td></tr></tbody></table>

led to the specification of the “to-be” versions for the various processes. In Table 2 we report the characteristics for the improved versions of the BPs. Within parenthesis we report the number of constructs for the version “as-is” for the same process. As can be noticed the two processes already in use could be made more efficient reducing the foreseen activities. On the other side the framework permitted to better specify the BP which is still under development. It is worth mentioning that we also validated the correctness of the derived processes requesting a deep review to the different civil servants involved in the delivery of the related services. This activity as been carried on asking to the civil servant to reproduce his/her activities with different fake input to the service. In all the simulations we carried on the “to-be” version of the process resulted to be adequate with respect to the civil servant expectations.

## 7 Conclusion and Future Work

In the PA domain requirements can come from many different sources and the deployed software often foresees the interactions of many authorities. Particu-
larly tricky to discover and represent are those requirements coming from laws
and internal regulations. In this paper we presented our experience in modeling,
analysis and reengineering BPs supporting the delivery of services to citizens. We
strictly cooperated with civil servants and domain experts to model processes
using graphical notation. The intuitive nature of the representation permitted
to conduct an analysis of the deployed processes and to identify many pitfalls.
Discovered issues have been classified in a framework and an improved version
(to-be) of the processes have been derived to overcome identified issues. The
result was really positive since the notation permitted to remove the “wall”
among technology experts and domain experts providing a common “blueprint”
on which to work. In the future we plan to observe how the novel BPs behave
and to derive measurements for the defined improvements. At the same time we
intend to continue our cooperation with the PA to experiment the approach on
other BPs.

Acknowledgement

We are indebted to our graduate student Barbara Petrini from the Master of
Science in Computer Science who helped us in preparing and conducting this
research. We also thanks Prefettura di Ancona for the fruitfull collaboration.

References

1. Weerakkody, V., Currie, W.: Integrating Business Process Reengineering with Information Systems Development: Issues & Implications Business Process Management. In: Business Process Management. Springer Berlin/Heidelberg (2003)

2. U.S.A.: Executive Summary — Creating a Government that Works Better and Costs Less. Technical report (1993)

3. Thong, J.Y.L., Yap, C.S., Seah, K.L.: Business Process Reengineering in the Public Sector: The Case of the Housing Development Board in Singapore. J. Manage. Inf. Syst. **17**(1) (2000) 245–270

4. Xenakis, A., Macintosh, A.: A Generic Re-engineering Methodology for the Organized Redesign of the Electoral Process to an E-electoral Process. (2006) 119–130

5. Ciaghi, A., Villafiorita, A., Woldemariam, K., Mattioli, A., Phan, Q.S.: Supporting Public Administration with an Integrated BPR Environment. **38** (2010) 50–59

6. Lindsay, A., Downs, D., Lunn, K.: Business process – attempts to find a definition. Information and Software Technology **45** (2003) 1015–1019

7. Roser, S., Bauer, B.: A categorization of collaborative business process modeling techniques. In: E-Commerce Technology Workshops, 2005. Seventh IEEE International Conference on. Volume 0., Los Alamitos, CA, USA, IEEE (2005) 43–51

8. Object Management Group: Business Process Model And Notation (BPMN) Version 2.0. (2011)

9. Mendling, J.: Metrics for process models : empirical foundations of verification, error prediction, and guidelines for correctness. Springer (2008)

10. van der Aalst, W.M.P., ter Hofstede, A.H.M.: YAWL: yet another workflow lan-
guage. Information Systems **30**(4) (2005) 245–275