Paper Title (use style: paper title)



Mobile Collaboration for Business Process Ellicitation from an Agile Development Methodology Point of ViewNelson BaloianDept. of Computer SciencesUniversidad de ChileSantiago Chilenbaloian@dcc.uchile.clCarlos RevecoDept. of Computer SciencesUniversidad de ChileSantiago Chilenbaloian@dcc.uchile.cl Jose A. PinoDept. of Computer SciencesUniversidad de ChileSantiago Chilegzurita@fen.uchile.cl Gustavo ZuritaDept. of Management Control and Information Systems. School of Economics and Business Universidad de ChileSantiago, Chilegzurita@fen.uchile.clAbstract---- Business process Modeling is an important activity in organizations that documents processes currently being performed or it may represent a design of a process that should be implemented. Process models are used to analyze them in order to improve, implement or just register them in order to document the process for new staff which should learn how to perform them. As in software engineering, there are methodologies guiding the business process elicitation activity. Accordingly, there have been also works proposing agile and lightweight methodologies for carrying on this activity. In this paper we present a tool which was especially developed for supporting an agile business process elicitation. It is based on requirements which can be derived from the description of the agile methodologies described in the literature. Two important characteristics of this tool are mobility and collaboration. We also report about an initial testing of the tool which has shown further advantages of using mobile technology in this scenario. Keywords- BP Elicitation, exploratory study, mobile collaboration, BPMN application. IntroductionBusiness Process Modeling (BPM) has been recognized to be an important activity in organizations. Business Process Elicitation is a collaborative activity needing research. The typical development of process models is done by analysts, although there are proposals to involve end-users in this activity [1, 2]. Business processes are needed to computerize currently manual processes, or to replace a computerized system which is not performing well under the current business context, or to train new employees about their future duties, or simply to document the current processes which currently are not formally described [3]. In the most common setting with analysts doing the process models building, end-users are still much needed. They are the source of knowledge concerning the processes since analysts are rather technology-oriented and do not have the domain experience to explain the processes in detail. Therefore, we have an instance of the widely known problem of knowledge externalization [4]. The most common methods of knowledge externalization in this case are interviews and workshops [5]. Users are visited by analysts who try to extract the needed knowledge to build the process models. Antunes et al. [2] have listed six main challenges for process modeling using technology: i) the automating a fiction problem [6], ii) the model-reality divide [7], iii) the model consistency problem [8], iv) the collective intelligence problem [9], v) the lack of flexibility problem [10], and vi) the missing tacit knowledge [11]. The focus of this paper is to deal with problem v), which can be explained as the insufficient time required planning, developing and deploying highly detailed business processes in the context of agile enterprises. This does not mean we are ignoring the other problems, but just we are establishing the emphasis.We assume that agile organizations need business process models as quickly as possible. Thus, we report here explorations with teams of analysts who may create prototype models while they are interviewing users. We also allowed the team members to work in parallel (distributed strategy), interviewing various users at the same time, if they felt that was convenient. Our purpose was to explore their needs for synchronous communication, convergence meetings, awareness mechanisms, information capture tools, and ultimately, the feasibility of the idea. The teams had available MOBIZ (Mobile Business Processes Capture), a tool developed by ourselves which allows BPMN models to be directly built from mobile devices (tablets and smartphones). The rest of the paper is organized as follows. Section 2 contains a bibliographic review of the subject. Section 3 presents the requirements for a tool which can support agile busine process elicitation. Section 4 describes the application we developed based on these requirements. Section 5 reports on a preliminary evaluation of the tool. Finally, Section 6 contains the Conclusions and future work. Related workBusiness Process Management (BPM) is an approach for describing and documenting business processes as an asset an organization has in order to manage their life cycles and analyze them for improving them. Gartner defines them as something which allows controlling the business processes in order to improve their agility and operational performance [11].According to [12] the main contribution of adopting BPM is to obtain organizational excellence in order to obtain advantages over other competing organizations. This is achieved by aligning the business requirements with the processes, actors and technologies supporting them. The main benefits of adopting BPM are a) Efficiency: better, faster and more cost effective; b) Visibility: knowing the current status of processes and business; and c) Agility: quickly adapt to changing business conditions. However, adopting a BPM approach in an organization has also some risks because it is a complex process and if it is not adequately addressed, it can fail causing high costs for the organization [12]. To adopt BPM is not only to identify, model and automate processes, but requires changes at organizational, methodological and technological levels of the organization.A fundamental part of BPM is business processes elicitation, which starts with understanding the activities involved and then identify its inputs, outputs, flow of activities, decision points, parallelisms and convergences [13]. In order to bring this to a model, it is necessary to use some kind of notation. For this there are two notations that are widely used today: BPEL (acronym for Business Process Execution Language) and BPMN [12]. BPEL is an XML-based language. As its name suggests, this notation is useful for when the model has to be used as input by process execution engines, like the one included in Oracle BPM Suite among others. BPMN is a graphical notation for modeling business processes. This notation is the most currently used by process analysts.Business processes elicitation is now considered a very useful tool not only for BPM adoption projects, but for any project aiming at improving business processes, redefining business strategies and requirements [13]. There are platforms using process models as the basis for the development of information systems to support business processes, such as Oracle or IBM BPM.A major concern in process elicitation is that process knowledge is spread among the agents involved in the process, either direct or indirect actors, hampering the collection and consolidation of the information necessary to model and document the process [14]. While there are techniques that have been proven to be effective in obtaining and consolidating information, we still observe problems related to this task [15].Most of the problems identified are given a place due to the complexity of organizations and the relationships between its parts, as well as how incomplete is the information handled by actors in the process, the changes that occur in organizations and the ambiguity between the information provided by various actors. The most common factors problems in lifting processes are:Partial Knowledge: The process managers may not fully understand the process, so it is necessary that several people involved in the task participate in the process modeling.Understanding: Analysts in charge of doing the process elicitation do not fully understand the business, so they may not do right questions.Access to information: Analysts may not have access to all relevant information such as already built models or annotations from other interviews. The analyst may not be able to collect the information from all relevant sources.Business vocabulary: There might be differences in the vocabulary analyst commonly use and the one used by the process performers.Techniques and methodologies: Analysts choose techniques according to their experience which may not be the adequate for the case [16].On the other hand, Verner argues that the process knowledge is tacit and local [17], as there is in the minds of those involved and each participant has their own vision of the process. He also raises awareness of the process that is essentially visual, so any technique used should be based on elements that they consider this feature. For these same reasons Bhaumik argues that it is recommended that process analysts use not one but several techniques, depending on the context of the project [16].It is then important to consider a number of techniques, both traditional and collaborative. The former are usually executed by an analyst or consultant who conducts interviews and workshops to managers of processes to get the information. The collaborative ones involve the participation of several people, processes actors, managers and analysts who interact with them to go seek knowledge about the process activities.While interviews and workshops with process managers remain the most used techniques [16], there are proposals seeking to supplement them which consider the participation of processes stakeholders and business experts in the construction of the models [18] [19]. Moreover, according to De Laurentiis, business processes elicitation should be done as quickly and efficiently as possible in order to maintain customer expectations [20], which make the task even more complex. RequirementsFrom the literature review in the previous section we can conclude that authors advocate for more agile methodologies for business process elicitation in the same way as agile software development methodologies do. According to [21] agile software development has three basic characteristics: frequent delivery,close communicationreflective improvementThis means, among other things, collaborative work among developers, close involvement of the final user (in this case, the processes stakeholders), fluid and constant communication between process analysts and process stakeholders as well as among analysts themselves, and incremental development with frequent deliveries in order to check the correct direction of development thus reducing the probability of rolling back big pieces of work. On this basis it is postulated that this tool has the following requirements:A mobile interface that allows the construction and editing terrain models. This interface must address the characteristics and limitations of mobile devices to be sufficiently simple and efficient for the initial survey (not as detailed) process in the fieldA mechanism to continue the work started in the mobile devices in a more complete interface on a desktop computer. The work on desktop computers should be in any application whose interface is at the height of the current applications for BPMN modeling.The work, at on mobile and desktop devices must be collaborative, in both on-line, allowing multiple users to work simultaneously on a model as well as off-line, allowing them to share and distribute the work.The above requirements are about the general but fundamental characteristics the application should have. With respect to the interface, we would like to add the following requirements: Portable, so it can be used in both a desktop and mobile with the fewest possible changes. In desktops is difficult to use a pencil and paper type approach.Coherent: both Interfaces, for the mobile devices and for the desktop should have a unified human-computer interaction paradigm. However, they have to accommodate to the characteristics of the screen, and particular pointing devices (mouse or touch-screen). Intuitive, in order to be used by users without prior knowledge of the tool. An interface based on gestures while it is convenient for those who know it can be complex to use for those who do not know.Flexible, in order to allow it to be informally used by people who have not expert knowledge on the BPMN standard for constructing models which can start with the very basic characteristics of the process that can gradually completed.Simple, in order to be used as part of the meeting without hindering it. This is because the mobile version of the tool is supposed to be used during the interviews with the process stakeholders. Complete, that is, it should allow constructing models complying with the BPMN 2.0 specification.Given these requirements, especially those regarding portability and coherence, we decided to implement this tool using HTML5 as this offers a number of advantages, some relevant to the development and others that are reflected in non-functional characteristics of the application, which can be only be developed with this technology. They include the following features:Since HTML5 is a platform-independent standard, it is expected that porting it to another platform will require less effort.Being a technology for web applications, it does not require installing special software to use it. Only a compatible web browser is necessary to run it. Since not all browsers fully comply with this standard we set the requirement that it should be tested to run flawless in the following browsers only: IOS SAFARI and FIREFOX MOBILE for ANDROID devices.It does not require special software development kits (SDKs), in contrast to other technologies which are device specific. This greatly simplifies the development process.the software tool: MOBIZAs mentioned in the previous section the tool has two interfaces, one for desktop computers and another for mobile devices of two applications. It was considered on the beginning to develop only the one for the mobile devices and then export the resulting model to a data format which can be read by the already existing tools. This was discarded because it would make the implementation of synchronous collaborative work among mobile and desktop users very difficult in the best case. The strategy to develop both versions of the interface was to first develop the desktop one without any constrains of size or interaction possibilities and then adapt it to the mobile scenario, fitting the workspace to the reduced screen size and adapting it to the interaction possibilities. The desktop InterfaceThe look and feel of the desktop interface was partially based on the one proposed by the BIZAGI process developer [], principally because it is a well known product among business process, so they will rapidly learn how to use the new tool, and because the interaction principle for creating new elements of the model starting from a contextual popup menu of existing elements works very well in both, the desktop and the mobile environments. The first element of the interface the user has to interact with is the menu bar of artifacts. It consists of a graphical menu containing icons for all artifacts defined by the BPMN 2.0 standard. The way in which a new element is created is shown in Figure 1. At the top of the screen border the menu bar shows all artifacts which can be placed at the workspace to create a BPMN graph. New ellemnts can be added by selecting, dragging and dorpping them on the workspace, initially empty. One of the most interesting features of MOBIZ partially taken from BIZAGI is the use of a context menu when interacting with an artifact on the workspace. We added some additional features in order to take more advantage of this interaction element. This contextual menu does not display actions to perform but a list of possible types of artifact that may follow the current one on the process being constructed. This context menu provides two alternative uses. The first one is the creation of a new device that will be immediately linked to the original object through a transition arrow. This, as seen in Figure 2, is done by dragging the device icon in the shortcut menu to the desired position for the new device, in a similar manner as would be done using artifacts bar.The task artifact on the left shows the contextual menu which displays the alternative of artifacts that can be created as follower for the current one by just dragging and droppingthe corresponding icon, as seen on the right. The other alternative is to create a transition between two already created artifacts. This is done in the same way as one would to create a new artifact, but instead of dragging and dropping the icon over an empty place of the workspace it is dropped over the target artifact. This can be seen in Figure 3. For this case, a restriction was intentionally added: this operation does not work if the dragged icon does not match the type of the artifact on which is dropped. The target device is marked as selected only when the icon is dragged over a correct icon and a transition arrow is created. This checking feature avoids possible ambiguities about what the user wants to do.On the left we see the task icon is selected and placed over an existing artifact which matches the one of the icon. This causes the creation of a transition arrow from the fisrt artifact to the second, as seen on the right. In addition to the above features some others were included from which we would like to mention the following:Automatic resizing of the workspace: The size of the canvas on which the model is built, rather than starting with a very large size as in most common applications, is adjusted to the size of the model and grows “around” the model. This avoids problems caused by having space excess. An example of this is when a model is not built in one corner of the canvas and then it might be hard to find.Drag & Drop of artifacts: All artifacts of the model are movable using Drag & Drop to change its position. This includes automatic adjustment of any transition arrow to or from the device displaced.Zoom: The zoom functionality includes an adjuster to fit the size of the model to the screen. This effect is achieved especially well thanks to the use of SVG (Scalable Vector Graphics) to create the model. As its names implies, SVG is directly scalable without loss of quality. This differs from what the built-in zoom functionality of browsers which zooms all the content of the page being displayed. This zoom only affects the view of the process model being constructed. Hotkeys: We included some hotkeys for artifacts removal (delete key), pixel by pixel shifting of artifacts (arrow keys) and zoom (shift key + mouse wheel).Double click artifacts: Double-clicking on any device (including transitions) displays a pop-up window with a form that contains all the information of the selected device and allows editing the name, description and/or type, the latter option is available depending on the kind of device in which the operation is performed.The mobile interface: The figure on the left shows a view of the full process model as it would be shown in a tall screen. The figure on right shows the actual view taken from screenshots of the tool displaying the piece of the model shown with a clearer background on the right. The picture on the top right shows the page with the header and footer hidden and the view on the right bottom with them. The Mobile InterfaceThe mobile browser interface was constructed by modifying the interface built for desktop browsers. For this reason, in this section, we describe only the differences between both interfaces.One of the main challenges in the adaptation of the interface, especially for smartphones, was to make optimum use of the limited space that is available on the screen.The first step was to make the diagram use 100% of the available screen space. To achieve this, we used a strategy in which all interaction objects external to the model itself were included in the header and footer sections of the page, which can be hidden or displayed by touching the screen. The result of this is shown in Figure 4.The mobile interface is composed by three main parts, which are the header (see Figure 5), the workspace and the footer. The function of the header is to give the user context information about what is happening on the system. This is done by displaying a short and simple text explaining the action currently being executed (in the figure 5, a new task is being created). If the action requires additional information the user can click on the icon and a pup-up window with additional information will be displayed. Before executing an action it should be confirmed or cancelled. For this, there are two buttons labeled with “yes” and “no”.The footer is used to display the Tools menu. This menu replaces both, the toolbar and the context menu used in the desktop interface. It seeks to accomplish the same tasks without having to use a mouse to drag items. Moreover, this bar contains an additional button for editing information artifacts, since on the interface for desktops this was done by double-click, which in the mobile interface is reserved for triggering other functionalities.The mobile interface: The header. Finally there is the body of the page where the process model is shown and the user can interact with it. This section uses all available space, except the one used for the header and footer when they are displayed. The “navigation” inside this section is implemented with gestures, as they are commonly implemented in other applications for mobile devices with touch screens, in order to ease the process of learning how to use the tool. The typical gestures we included are those shown in Figure 6. Gestures used for navigation in MOBIZ Zoom In and Zoom: Used for zooming the model with respect to the screen. By making the gesture of bringing fingers closer (zoom in), artifacts will become larger and will fit a smaller portion of the diagram on the screen. Making the gesture of separating the fingers (zoom out) the artifacts will be smaller and will fit a larger portion of the diagram on the screen.Drag: This changes the relative position of the diagram with respect to the screen by an amount proportional to the distance the finger have been dragged on the screen. This causes parts of the diagram that were hidden will be shown now.Sweep: The effect is similar to drag, with the exception that the amount of displacement of the diagram is proportional to the speed with which the gesture is made, not its length.Double-touch on an artifact: In addition to selecting the artifact, this gesture will enlarge the artifact’s view in order to have it occupying most of the screen. Touch twice on the bottom: This alternate between two levels of zoom, one where artifacts are very large and another where most of the diagram is displayed. Furthermore the diagram immediately is moved in order to leave the touched point at the center of the screen.Horizontal sweep weep with two fingers: This gesture can only be done when there is a previously selected item. The objective of this gesture is to enable the navigation through the transitions of the BPMN artifacts, in other words, following the arrows of the diagram. Thus, to make the gesture to the right will change the selected artifact to the one to the right, following the arrow (random if more than one) producing a similar effect to double tapping the artifact to which this arrow points. The same happens the gesture is made to the left, following the arrow in reverse. If there is no arrow in the selected direction nothing happens.Vertical sweep with two fingers: This gesture is used after the previous one, when there is more than one artifact after or before the selected one. As said, in this case the tool will chose randomly one of them with the previous gesture. This one allows navigating between the alternatives. Evaluation We performed an initial experiment in order to have first feedback data about whether the with engineering students from a course about digital communication systems in order to evaluate if the principles of situated learning were correctly applied and if this specific activity did introduce an added value to the learning process. The experiment was performed by 28 students, divided in seven groups of four participants each. Two of them took the role of planners and two the role of measurers. The activity was performed after having the theoretical sessions in the classroom explaining signal propagation and their simulation models as well as the practical sessions in the laboratory where they learned how to measure signal strength with special equipment. In the first step of the experiment, planners ran the simulation software calculating the theoretical signal strength values using all models for a pre-designated area in the city where the university is located. Simultaneously, measurers went to pre-defined locations to measure the signal strength. The locations were strategically chosen by the teacher for being easily accessible and also having interesting conditions for studying the signal propagation phenomena, like being located near hills or group of buildings, which will challenge the simulation results as these elements introduce local variations in the propagation pattern. For performing the second step of the learning activity which corresponds to the discussion of the results, students were given three days in order to compare real and simulated signal strength values, comment about the differences they found among them and trying to explain them. After this they presented the conclusions to the teacher and the rest of the class. After finalizing the learning activity students were asked to answer a questionnaire consisting of assertions which the students evaluate to which degree they agree or not with them using the Likert scale (1-strogly disagree, to 5 strongly agree) Each assertion is related to one or more components related to situated learning (C1 to C7) which were described in section III. The assertions and their relation to the different situated learning components is the following: The various developed activities helped me to improve my understanding about how to apply the signal propagation models. - This assertion is related to the components C1 and C2 of the Situated Learning framework (see section II).The different perspectives both roles provide about the problem being learned helped the group in solving it. - This assertion is related to the component C4.The practical activity combined with the theory of signal propagation models helped me to reflect about how to better solve the problem. - This assertion is related to the components C6 y C7. The system supported the collaboration among the various members of the team. - This assertion is related to the component C5.The collection of relevant data made on the field helps to understand key aspects of the problem being studied. - This assertion is related to the components C1 y C2.Observation of the measured data and analysis of simulated data was of great help while solving the proposed task. - This assertion is related to the components C5 and C7.The obtained results are tabulated in the Table 1. As we see, in general all assertions have a mean value above the “neutral” level. The worst score was 3.4 and was obtained for Q3, which relates to the reflection process, and Q7, which relates to the usability of the whole system. This means that there is still room for improving the human-computer interaction aspect of the developed applications. The best score was obtained for Q5, which relates to the value added by the activity on the field to the learning process. This means that the work on the field is the aspect of Situated Learning that is best implemented by this learning activity. Also Q3, Q4 and Q6 obtained good evaluations. These are mainly related to collaboration (C5) and articulation (C7) aspects. A fact worth to mention is the results obtained from the questionnaire the students have to answer at the end of the semester in order to give their opinion about the whole course. Traditionally, students complained that the course was too theoretical. For the first time since the questionnaire is implemented students did not mention that complain.Conclusions The learning of wireless network planning is a difficult task due to the fact that it requires a non-trivial theoretical background as well as practical experience in order to understand a problem, which is in most cases ill defined. It is therefore important that the students have the opportunity to face the wireless network planning process in conditions as close to the real situation as possible. Based on the situated learning theory, we developed a learning activity and the necessary computer technology to support it, which allows students to have an experience that helps them to realize many of the most important challenges and problems of this process. Compared with other efforts reported in the literature, the work presented here goes one step forward as it envisages a combination of in-classroom theoretical learning sessions with laboratory and on the field work. It also encourages collaboration and reflection. Results from the experiment tends to support this assertion, since the results of the questionnaire answered by students after the experiment shows high degrees of agreement with assertions related to these aspects. The activities and results described in this paper contribute with new insights and perspectives related to the design of situated learning activities using mobile, positioning and web technologies. The outcome of our efforts provide some indications that well designed learning trajectories with solid theoretical foundations can successfully combine outdoors group learning experiences with learning activities in the classroom to provide learners with meaningful activities in order to learn and to explore a complex topic in authentic settings, reason and to argument in order to come to the solution of a problem, collaborate in order to construct common knowledge, and visualize and reflect upon relevant matters and to support complex thinking.ReferencesBorges, M., Pino, J.A.: PAWS: towards a participatory approach to business process reengineering. Proc. of the 5th international workshop on groupware (CRIWG), Cancun, Mexico, IEEE CS Press, pp. 262-268 (1999).Antunes, P., Simoes, D., Carrico, L., Pino, J.A.: An end-user approach to business process modeling. J. of Network and Computer Applications, article in press (2013).Antunes, P., Herskovic, V., Ochoa, S., Pino, J.A.: Modeling highly collaborative processes. Proc. of the IEEE International Conference on Computer-Supported Cooperative Work in Design, Whistler, BC, Canada (2013).Wang, H., Zhao, J.L., Zhang, L.J.: Policy-driven process mapping (PDPM): Discovering process models from business policies. Decision Support Systems 48, pp. 267-281 (2009).Jennings B, Finkelstein A. Flexible Workflows. In: Voudouris C, Owusu G, Dorne R, Lesaint D, editors. Service Chain Management: technology innovation for service business. Heidelberg: Springer; 2008. p. 171-85.Schmidt R, Nurcan S. BPM and Social Software. In: Ardagna D, Mecella M, Yang J, editors. BPM 2008 International Workshops: Springer; 2008.Antunes P, Mour?o H. Resilient Business Process Management: Framework and Services. Expert Systems With Applications. 2011;38:1241-54.Erol S, Granitzer M, Happ S, Jantunen S, Jennings B, Johannesson P, et al. Combining BPM and social software: contradiction or chance? Journal of Software Maintenance and Evolution: Research and Practice. 2010;22:449-76.1Bruno G, Dengler F, Jennings B, Khalaf R, Nurcan S, Prilla M, et al. Key challenges for enabling agile BPM with social software. Journal of Software Maintenance and Evolution: Research and Practice. 2011;23:297-326.Silva A, Rosemann M. Processpedia: an ecological environment for BPM stakeholders' collaboration. Business Process Management Journal. 2012;18:20-42.Gartner. (2005). Business Process Management: Preparing for the Process-Managed Organization.Buelow, H., Das, M., Deb, M., Palvankar, P., & Srinivasan, M. (2010). Getting Started with Oracle BPM Suite 11gR1. New York: PACKT.Baloian, N., Zurita, G., Santoro, F. M., Mendes Araujo, R., Wolfgan, S., Machado, D., y otros. (2011). A Collaborative Mobile Approach for Business Process Elicitation. Proceedings of the 2011 15th International Conference on Computer Supported Cooperative Work in Design.Gon?alves, J., Santoro, F., & Bai?o, F. (2010). A Case Study on Designing Business Process Based on Collaborative and Mining Approaches. Proceedings of the 14th International Conference on Computer Supported Cooperative Work in Design (CSCWD 2010).Wang, H. J., Zhao, J. L., & Zhang, L. J. (2009). Policy-Driven Process Mapping (PDPM): Discovering process models from business policies. Decision Support Systems 48, págs. 267-281.Bhaumik, S. S., & Rajagopalan, R. (2009). Elicitation techniques to overcome knowledge extraction challenges in ‘as-is’ process modelling: perspectives and practices. International Journal on Process Management and Benchmarking, 3(1).Verner, L. (2004). The Challenge of Process Discovery. BPTrends.Grosskopf, A., Edelman, J., & Weske, M. (Septiembre de 2009). Tangible Business Process Modeling - Methodology and Experiment Design. Proceedings of 1st International Workshop on Empirical Research in Business Process Management (ER-BPM '09).Hoppenbrouwers, S., & Schotten, B. (2009). A Game Prototype for Basic Process Model Elicitation. Lecture Notes in Business Information Processing, 39(7), págs. 222-236.Laurentiis, G. (2011). Metodología BPM:RAD? – Rapid Analysis & Design para la modelización y dise?o de procesos orientados a tecnologías BPM. En El Libro del BPM: Tecnologías, Conceptos, Enfoques Metodológicos y Estándares. Madrid, Espa?a: Club-BPM.Cockburn, A.: ‘Agile software development’ (Addison-Wesley, 2002) ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download