Process Innovation: Redesigning an Enterprise Backbone System

Keywords: IT-enabled innovation, Business Process Management, Flexibility, Process Design, Process Innovation, Enterprise systems

This case study covers the story of a process reengineering effort at Belgacom Mobile, the largest Belgian mobile telecommunications operator. It describes how a smart combination of theoretical concepts can lead to process innovation, and product innovation. The process innovation effort consisted of a large automation pillar and the rebuilding of the enterprise backbone system SPOMS. Architectural principles were applied to allow the redesigned process to be flexible and capable of dealing with newly emerging SIM card types and technological advances. The sub-processes will be orchestrated by the process owner who controls the entire process from a process dashboard. This case shows the potential benefits of Business Process Management (BPM), ITenabled innovation and Product Factory. The redesigned SIM card ordering process thus provides a sustainable answer to the ever shortening life-cycle of products and technologies, SIM cards in particular, and the call for process flexibility in fast changing environments.

The contribution of this project to the general understanding IT-enabled innovation lies in the innovative approach. Namely, product and process were separated from each other by means of Production Process ID creation. The redesigned SIM card ordering process thus provides a sustainable answer to the ever shortening life-cycle of products and technologies, SIM cards in particular. The redesigned sub-processes are orchestrated by the process owner who controls the entire process from a process dashboard. In terms of performance improvement, the project resulted in (1) increased process flexibility (2) and consistency, (3) dramatically shortened lead-times and (4) better control over the process.

Introduction

In order to survive and thrive in a highly competitive business environment, organizations need to be in control of their business processes. Moreover, organizations that find themselves in a sector with galloping technological developments experience the necessity of flexible processes characterized by a high degree of product independence [START_REF] Becker | Process Management: A Guide for the Design of Business Processes[END_REF]. Belgacom Mobile, market leader in the Belgian mobile telecommunications market, finds itself in such a position and is continuously pressured by the smaller challengers in the market. Furthermore, the mobile telecommunications sector is known to develop at a rapid pace, driven by technological advances. It is, therefore, crucial for Belgacom Mobile to be capable of managing and optimizing its business processes and on top of that keeping them adaptable to emerging technologies with the support of a reliable enterprise IT system.

The severe fight for the customer due to the market situation results in large promotional marketing campaigns, for example inclusion of free SIM cards with popular magazines. These campaigns are typically dependent on temporary trends and needed quick response from the back office processes producing and supplying the SIM cards. Simultaneously new types of SIM cards are being introduced as a result of technological advances, requiring to be embedded in the existing process structure.

Due to these circumstances the SIM card ordering process at Belgacom Mobile, a core business process for the company, was under increasing pressure. In 2006 the supply chain management team realised that the process and its supporting technology SPOMS (SIM card Purchasing Order Management System) needed a thorough reengineering. Most of the expertise on the old tool had left the company and furthermore it was starting to become clear that the process was not as flexible and agile as required to react on requests from the marketing department. Lastly, the process as it was, posed an impediment for product innovation because it needed reworking for each and every new type of SIM card that was being introduced. Some decisive action to set this situation right was necessary. After several rounds of proposals an innovative solution came to light to automate and simplify the SIM card order process.

As stated in the official business case document the objective was to "reengineer the current SIM card order management process to make the process future-proof, efficient and flexible". Whereas at first, they had a mere automation of the existing process in mindit was very labour intensiveover time the mindset shifted towards an approach that emphasised both process reengineering and automation. Based on the business case developed by the supply chain team, stressing the numerous benefits of reengineering, and the risk associated with not doing the project, the project received a 'MUST DO' label from the review committee. Thus the project became a high strategic priority and gained access to the necessary resources.

This case study is specifically intended to formulate an empirically evidenced answer to these research questions, validating the existing body of knowledge and theory on IT-enabled process innovation and enterprise systems: How does IT support enterprise processes in turbulent environments? Does a combination of BPM and SOA truly deliver superior business results? What are the key success factors in an ITenabled process innovation effort?

The originality of the final project set-up presents this case as the perfect example for showcasing IT-enabled process innovation. First, relevant concepts of BPM, ITenabled innovation, architecture and process-specific terms are situated. Next, the context, business case and set-up for the project are described. Subsequently, the project's main features and particularities are outlined. To conclude, the results of the Belgacom Mobile project are presented and the learning points and contributions are explained.

Theoretical Background

Processes and Flexibility: An Architectural Approach

Flexibility is generally defined as the ability to adapt to different circumstances. It is one of the main goals of process management since flexible processes are appreciated assets to deal with changing market demands. IT infrastructure needs to allow such flexibility in business processes. Process management systems are according to Weske [START_REF] Weske | Business Process Management: Concepts, Languages, Architectures[END_REF] narrowing the gap between business objectives and the technology that is there to help achieving those goals. Notwithstanding the fact that IT systems have shown to be capable of enhancing process flexibility there are mixed feelings towards their role in all this. Especially the widespread implementations of diverse ERP systems have led to discussion. One could argue that adapting processes in such a way that they would fit the prescribed ERP software reference processes is hardly a practice that promotes process flexibility. If an organisation manages its processes well, they can be considered as a source of competitive advantage. On the other hand there is a tendency towards the use of industry best practices and reference models, turning certain processes more and more into a commodity. Working on process innovation expectedly results in superior business processes that differentiate an organisation from its competitors.

Process flexibility comes with two major requirements as stated by Stohr and zür Mühlen [START_REF] Zür Muehlen | Business Process Management: Impact on Organizational Flexibility[END_REF]: "First, there must be a capability to develop new processes and change existing processes rapidly and inexpensively, and secondly process work must be flexible within the scope of a given process design." The former implies that (new) processes must be designed in such a way that they can be deployed rapidly. Several enterprise process management systems now provide the ability to transform process models into executable processes. The underlying technology is crucial since it must allow for interoperability with other internal and external IT applications. Thus, new processes can easily connect to other systems and reuse parts of existing processes as services that can be invoked.

With regard to the SPOMS project, both the Supply Chain Manager and the external consultants involved in the project agreed that an architectural approach was best suited for this particular project. Specifically, Service Oriented Architecture (SOA) is said to bring various advantages to business processes [START_REF] Beimborn | Drivers and Inhibitors of SOA Business Value -Conceptualizing a Research Model[END_REF][START_REF] Trkman | SOA Adoption Phases: A Case Study[END_REF]. Numerous blogs, vendor reports and white papers have spread the belief that SOA and BPM are two sides of the same coin and that both approaches deliver the best results when combined [START_REF] Behara | BPM and SOA: a strategic alliance[END_REF][START_REF] Carter | The role of Business Process Management in SOA[END_REF][START_REF] Malinverno | BPM and SOA are better together[END_REF].

SOA was defined as a "component model that interrelates the different functional units of an application, called 'services', through well-defined interfaces and contracts between these services. The interface is defined in a neutral manner that should be independent of the hardware platform, the operating system, and the programming language in which the service is implemented" [START_REF] Walker | IBM business transformation enabled by service-oriented architecture[END_REF]. Loose coupling and reusability of services are the cornerstones of the interest in SOA as a means to make business processes more agile, a condition for sustainable success in today's business environments. Both legacy systems and newly developed applications can be formulated as a set of services as well as external systems [START_REF] Brahe | BPM on top of SOA: Experiences from the financial industry[END_REF]. Each business process can call on these services when needed. SOA requires the set-up of a new architectural layer of abstraction -at the service level -between processes and systems. Loose coupling stands for the fact that the service requester should not be aware of the structure that underpins the requested service [START_REF] Conlon | Information Extraction Agents For Service Oriented Architecture Using Web Service Systems: A Framework[END_REF]. A recent literature study showed that SOA literature has exponentially increased in the last few years [START_REF] Sidorova | Business process research: a cross-disciplinary review[END_REF]. In another study Becker et al. [START_REF] Becker | Value Potentials and Challenges of Service-Oriented Architectures[END_REF] concluded that SOA adoption is still in its early phase.

Turbulent business environments call for adequate approaches to provide robust IT support for business processes. El Sawy and Pavlou [START_REF] El Sawy | IT-Enabled Business Capabilities for Turbulent Environments[END_REF] stated that "using an SOA and web services is an effective way of conserving IT investments because it removes the need for massive integration and re-integration expenditures when requirements change". The flexibility of modular business processes and supporting IT systems lies in the quick adaptation capabilities when the business environment changes, and in this way affects the business processes. However, SOA implementation involves several challenges. First of all, identifying and defining services could pose a problem to organizations. Another challenge of SOA is the involvement of the business in the process [START_REF] Bell | From the Front Lines DOA with SOA[END_REF]. Therefore alignment between business and ICT is a key success factor for SOA implementation. Finally, SOA should never be a strategy in its own right, but should be a decision to support the organizational strategy [START_REF] Baskerville | Extensible Architectures: The Strategic Value of Service-Oriented Architecture in Banking[END_REF].

Business Process Management (BPM) is an essential capability for many organizations. It provides a horizontal view of an organization's core business processes and the organization's capability of managing, improving and controlling these processes [START_REF] Davenport | Process Innovation: Re-engineering Work Through Information Technology[END_REF]. Zairi [START_REF] Zairi | Business process management: a boundaryless approach to modern competitiveness[END_REF] defines BPM as "a structured approach to analyses and continually improve fundamental activities such as manufacturing, marketing, communications and other major elements of a company's operation." Over the past years, the potential benefits of BPM have repeatedly been addressed in management literature. Among the reported benefits we note: increased process efficiency [START_REF] Harmon | Business Process Change: A guide for business managers and BPM and Six Sigma professionals[END_REF], higher speed-to-market, cost effectiveness, enterprise process coordination [START_REF] Davenport | Process Innovation: Re-engineering Work Through Information Technology[END_REF], and strategic alignment [START_REF] Zairi | Business process management: a boundaryless approach to modern competitiveness[END_REF][START_REF] Lee | Business Process Management: a review and evaluation[END_REF][START_REF] Hammer | Reengineering the corporation[END_REF]. One of the key factors in this case is the benefit of increased organizational flexibility: "The documentation, improvement and automation of these processes as a result of various competitive and regulatory pressures should lessen the internal rigidity of organizations. Processes also serve as the link between an organization and its business partners. To the extent that interorganizational processes are improved, documented and automated, one would expect that the ability of the firm to interact flexibly in its environment should be improved" [START_REF] Zür Muehlen | Business Process Management: Impact on Organizational Flexibility[END_REF].

IT-enabled Process Innovation

As IT becomes ubiquitous in society and companies it is inherently important for processes as well. In some environments process innovation relies on the potential to adapt within the underlying IT infrastructure. IT systems and infrastructure therefore need to be designed in such a way that it enhances an organisation's capability to innovate. Any process innovation effort needs to take into account the IT infrastructure it impacts as a factor that could either enable or hamper the chances to succeed. Mitchell and Zmud [START_REF] Mitchell | The effects of coupling IT and work process strategies in redesign projects[END_REF] incorporate under IT infrastructure all ''enabling technologies, sourcing arrangements, and policies that form an intricate system of information-related activities." Getting a hold of such a system is quite difficult if its parts are scattered over a multitude of both internal and external parties. Each particular element could potentially make or break redesign efforts. So therefore, when the opportunity arises IT infrastructure should be designed in such a way that they enable rather than obstruct process innovation. Designing a robust business process goes often hand in hand with reviewing and redesigning major parts of the IT infrastructure which in itself can be an innovation [START_REF] Mitchell | The effects of coupling IT and work process strategies in redesign projects[END_REF]. In the SPOMS case the IT presence was undeniable and obviously the former IT infrastructure was not at all enabling innovation, rather the opposite. Therefore the IT department was involved early on leading to a solution that was not only supported but also driven by multiple departments -including IT -where all involved parties acknowledged that the IT infrastructure to be developed had to be not only efficient in the short term but also enabling growth and innovation in the long term. The infrastructure has thus become a dynamic capability [START_REF] Eisenhardt | Dynamic Capabilities: what are they?[END_REF] for Belgacom Mobile, allowing them to adapt to future market requirements.

Information Technology

Process Innovation Process Flexibility and Scalability Fig. 1. IT-enabled process innovation (adapted from [START_REF] Davenport | Process Innovation: Re-engineering Work Through Information Technology[END_REF] Investing in IT backbone systems has a positive impact on the process innovation capability. Research by Kim and Kim [START_REF] Kim | The Impacts of IT Investment Directions and Strategies of Supply Chain Management Implementing Enterprises on Business Performance[END_REF] has shown that investing in IT to deal with dynamic business markets provides a competitive advantage through enhancing a firm's ability to innovate internal processes. Organisations that are able to adapt processes flexibly to changing environments hold an advantage over their less flexible competitors. These insights correspond with the statements by Stohr and zür Mühlen [START_REF] Zür Muehlen | Business Process Management: Impact on Organizational Flexibility[END_REF] that process flexibility allows organisations to "rapidly assume new competitive positions and to act proactively to achieve competitive advantage". A combination of optimised processes and smart supporting IT systems should result in opportunities to innovate service and product delivery, and to compete in fast changing environments. Process flexibility can help an organisation to deliver new products or services to the market as fast as possible and to react swiftly on market changes [START_REF] Zür Muehlen | Business Process Management: Impact on Organizational Flexibility[END_REF].

According to Davenport [START_REF] Davenport | Process Innovation: Re-engineering Work Through Information Technology[END_REF] IT has an impact on process innovation in several ways. IT brings opportunities to eliminate human labour from a process, to capture process information to better understand the process, to change the sequence of the process or enable parallel activities, to track the status of the process, to improve process analysis and decision making, to coordinate a complex process, to coordinate between tasks and processes, to capture and distribute knowledge and, finally, to eliminate intermediaries from the process. Many of these opportunities are supported by the SPOMS case. On the other hand Davenport [START_REF] Davenport | Process Innovation: Re-engineering Work Through Information Technology[END_REF] admits that IT can be a constraint for process efficiency and innovation. The SPOMS case shows that, if IT systems become too complex for example, they pose a barrier for the performance of the process. The SPOMS IT systems landscape is very complex and dispersed. It is often difficult, expensive and time-consuming to replace all legacy systems by a new one but that can be dealt with in an elegant way by opting for an architectural approach where the process is supported by an orchestrating instance (in this case the SPOMS dashboard) communicating with existing legacy systems and using them as a service.

Apart from technological conditions, a number of other conditions needs to be in place. Business processes are unlikely to be efficient and/or flexible if there is no clearly defined ownership, if the processes are not transparent, etc. A typical symptomatic problem, especially in larger organisations, is that all subsystemsi.e. departments, geographic regions, business unitsact as islands in the organisation although they are supposed to function as one system. The issue gets even more of a barrier if business processes involve many 3 rd party interventions, as in the SPOMS case [START_REF] Lawrence | Differentiation and Integration in Complex Organizations[END_REF]. Ever since large organisations have existed specialisation and integration have to be balanced. Working on process innovation should start from there. Process innovation efforts should not focus on mere automations of processes but on clarifying activities and roles and organising and optimising the allocation and execution of those. Hence, process innovation projects are both organisational adaptations and an IT infrastructure supporting that particular business process [START_REF] Mitchell | The effects of coupling IT and work process strategies in redesign projects[END_REF].

IT-enabled Process Innovation at Work: SPOMS

For Belgacom Mobile, flexible and efficient core processes are a strategic objective. In order to be effective, a redesign effort should reconsider process activities and resources, and how they are conceived, planned and implemented [START_REF] Damanpour | Organizational innovation: a meta-analysis of effects of determinants and moderators[END_REF]. Davenport [START_REF] Davenport | Process Innovation: Re-engineering Work Through Information Technology[END_REF] categorizes redesign projects as process innovations "when they produce radically new configurations of assets and activities". If the innovation effort is characterized by a high degree of information technology (IT) involvement, it is described as 'IT-enabled innovation'.

In the SPOMS case, the need to drastically innovate the process and its underlying IT system was obvious. The burning platform for initiating the project was the imminent risk of a system breakdown, with considerable consequences for the entire ordering process and hence for the overall position of Belgacom Mobile in a highly competitive market with mobile customers. Given the evident need, the project could be approached simultaneously as an opportunity to make the SIM card future-proof, thanks to a flexible and scalable design. Business processes in an environment such as the business environment in which Belgacom Mobile operates, with a multitude of supporting IT systems, are highly interdependent. In such circumstances "IT alters the ways in which people work and execute business processes, both within the enterprise and with business partners and customers" [START_REF] El Sawy | IT-Enabled Business Capabilities for Turbulent Environments[END_REF]. As far as Belgacom is concerned, IT investments serve three purposes, which indicate the intended benefits accruing from IT: firstly, IT is an enabler for running the business (enabler); next, IT can help to grow the business (scalability); and lastly, IT has the ability to transform the business (flexibility). The SPOMS case could be regarded as an investment supporting each of these purposes.

Shortterm

Run the business: An indicator of how much of the IT resource is consumed and focused on the continuing operation of the business. This largely covers maintenance, renewal, and capacity-related expenditure.

Grow the business: An indicator of how much of the IT resource is consumed and focused on developing and enhancing IT systems in support of business growth (typically organic growth). New projects are captured in this category.

Midterm

Transform the business: An indicator of how much of the IT resource is consumed and focused on implementing technology systems that support new business models, structurally reduce the total cost of ownership and create sustained efficiencies.

The SPOMS Project

The SPOMS project scope included a myriad of processes, starting from master data creation in an ERP software module, up to the hand-over of the SIM card data to the Order Management System and IT integration domains, while incorporating many third parties outside Belgacom Mobile, such as SIM suppliers, product suppliers, logistics providers, Mobile Virtual Network Enablers (MVNEs) 1 and Direct Mobile Virtual Network Operators (MVNOs) 2 . Together these processes constitute the supply chain process for ordering SIM cards at Belgacom Mobile.

The SIM card supply chain process at Belgacom Mobile, as it formerly existed, still involved a lot of manual operations. SCM administrators were responsible for monitoring the entire process, keeping a spreadsheet overview based on a purchase order number reference, generated by the ERP software. Next, they had to send out a spreadsheet file with procurement details to a number of third parties such as distributors, suppliers, and packagers, each requiring different types of files. Therefore they had to rework the response file to the proper layout and in most cases send this new file by e-mail to the addressee. Generating these files manually was a timeconsuming practice, leaving ample room for errors. Depending on the SIM card type, the procurement process could also differ, which further complicated the follow-up of the entire process. Errors could easily go unnoticed and remain unreported. Moreover, each party involved in the process had different ways of communicating with Belgacom Mobile. The process for special commercial campaigns had a total lead time of 3 months (i.e. from start-up of the campaign until stock is available to launch on the market). Finally, the process capacity was a limiting factor for the sales volume of SIM cards by Belgacom Mobile.

The imminent danger of a failure in the complex tangle of applications and entities posed a real threat to the business continuity of Belgacom Mobile. Errors in this core process could severely damage Belgacom's reputation and brand image. The emergency of the situation prompted Belgacom Mobile to assign a 'MUST DO' label to the SPOMS project, meaning it had strategic value for the company and was high on the priority agenda. The IT department and the marketing department agreed from the start that reengineering of SPOMS was a necessity and lent their full support to this project. The Supply Chain Manager and the external agency that was hired to execute the project opted from the start for an architectural end-to-end approach. Therefore, an IT project architect was involved in the project team early on. With reference to the 'old' process, the Supply Chain Manager stressed the urgent need for radical change: "We are currently facing a serious risk of business continuity failure. At the time, the market was growing and customers were becoming more demanding in terms of lead time. Frankly, I do not think we would have been able to cope much longer. We simply could not scale, let alone be more flexible." The SIM card Product 1 MVNE: Mobile Virtual Network Operators enable the activation of the SIM cards on the network. This party needs to receive the technical information through an electronic file. Belgacom Mobile performs the procurement of the SIM cards, but the MVNE activates the SIM cards on the network. 2 MVNO: A Mobile Virtual Network Operator is a provider of SIM cards that actually uses Belgacom Mobile services to operate. These operators receive SIM cards with a specific design from the logistics provider through the SIM card ordering process, but they do not receive the SIM card data in an electronic format. They are called virtual as they do not operate themselves, but use Belgacom Mobile as provider while using their own branding.

Manager, being the main internal customer of SPOMS, acknowledges this: "At the marketing side we were welcoming every attempt to considerably reduce the time-tomarket for card introductions.

The business case for the SPOMS project included the following objectives: 1.

Integration of the many departments and business partners 2.

Reducing manual operations 3. Standardization 4.

Decreasing total lead time 5.

Increasing production process capacity

The basis for the set-up of SPOMS was inspired by several theoretical principles. These principles served as a general guideline for successfully redesigning and automating the process.

 Making the solution flexible to allow for adaptation to future requirements and reuse of existing components using the principles of Service-Oriented Architecture (SOA), web services and object-oriented programming where possible.

 Centralized approach to process governance and ownership, using a dashboard to act as a 'process orchestrator'.

 Making the processes product independent, thus building a product factory, to allow flexibility in designing new products in the day-to-day product innovation at Belgacom Mobile.

Dashboard Product Design Data

Level 0 Process PPID

Fig. 3. Belgacom Mobile SIM card ordering process reengineering project overview

The SPOMS project presents two new features that are being introduced as innovations to the former process: the creation of a level zero process map as a representation of the situation of the SIM card ordering and activation process (see figure 3), and the creation of the SPOMS dashboard in order to provide the user with an overview of all current purchase orders in the process (see figure 3).

An Architected Process Solution

First of all, the as-is process was critically examined and completely redesigned. The newly developed process model was described at the highest level by a generic level zero process that can be applied to all existing SIM cards types and can easily be adapted when new SIM card types are being introduced. Using the level zero process contributed to simplifying the SIM card ordering process and capturing all necessary steps in the entire business flow, regardless of the type of SIM card. This enabled Belgacom Mobile to separate the processes from the products, thus increasing effectiveness and enabling the definition of new products with specific process flows.

The idea behind the SPOMS concept was to create one general flow -the so-called level zero process -that can be applied in all cases and to all production processes (see figure 4). Because not every step in the level zero process needed to be performed for all of the production processes, guidelines had to be developed to indicate what steps were relevant in which cases. These decision points are saved in production process templates. For each production process ID, the actions to be performed are identified beforehand. When a SIM card resource or SIM pack is defined as a material in the ERP software, a production process ID needs to be assigned to it. This enables SPOMS to decide which paths to follow when ordering these materials.

The Logistics Manager explains the new process as follows: "This new process is nothing like the old one. Before, we had no real overview of the status of orders for new cards, responsibilities were not centralized, and everyone seemed to be constantly working in fire-fighting mode. We managed to reengineer what used to be a very complex and burdensome business process with a lot of manual interventions to an almost fully automated, streamlined and transparent process that not only interconnects internal departments but also some external partners." Fig. 4. The Level 0 Belgacom SIM card ordering process

Centralized Process Governance

Secondly, the installation of a dashboard was an important project milestone. The purpose of the dashboard was to provide a single screen overview of all purchase orders currently in progress and to become the primary tool for steering the process. The dashboard would provide the tools for one-click generation of the input files for suppliers, starting the pre-activation scheduling, adding order-specific characteristics such as serial numbers, et cetera. Every step of the SIM card ordering process has been added as a status to the dashboard, which enables the user to view up-to-date and accurate status information for each purchase order item line.

The SPOMS dashboard is the core component of the SPOMS solution. It is the heart of SPOMS, from which most of the functionalities in the process can be accessed in an easy and intuitive way. The dashboard acts as a 'process orchestrator', and is the leading application triggering actions throughout the entire process by means of web services. The dashboard also keeps track of the status of interfaces and actions in the ERP system and in related internal and external systems. All interfaces that leave or enter SPOMS update the relevant dashboard statuses for the individual purchase order items.

The dashboard is the main tool for Logistics to perform the day-to-day follow-up of the SIM card procurement process, as it shows the status in ordering, production, quality testing and delivery of SIM cards and SIM products (or packs). The SPOMS dashboard was conceived as a native ERP transaction screen, retaining the same look and feel as the other ERP transactions.

The main purposes of the SPOMS dashboard can be summarized as follows:  To be the main tool for the SIM card purchasing follow-up on a daily basis, visualizing the purchase order item status throughout the entire process.  To be the orchestrator of the SIM card ordering process, triggering all the actions needed to complete the process. Integrating the level zero process and the dashboard functionality, however, implied an optimisation of the current master data creation procedure. For each SIM card production process type (PPID), a template was prepared specifying the dashboard functionalities and statuses that are relevant for that particular template. For each newly developed SIM card, the template already defines which process steps the card will have to go through. Furthermore, the technical approach adopted for the SPOMS project assured that all the SIM card data formatting and required by the level zero process to interface with other technical components of Belgacom Mobile and the various third parties, are performed correctly and in a secure way.

Project Implementation Challenges

Due to the complexity of the systems integration, the project presented multiple challenges. On the architectural level, two major challenges had to be addressed. First and foremost, data consistency had to be carefully safeguarded between all of the integrating systems. Secondly, all sub-processes needed to be aligned and the possibility to initiate, follow up and perform error handling had to be integrated. In order to cope with these challenges, the decision was made to adopt a process orchestration or centralized process approach, rather than a decentralized process approach. Process orchestration implies that the process is fully controlled and organized from one central location, and that every action/service reports back to the process controller. As shown in figure 1, for the SIM card ordering process, all actions are initiated and followed up in the SIM Card Ordering Dashboard, which acts as the process controller.

This orchestrated way of working for SPOMS provides the following advantages:  A status overview in the ERP system was established showing the current process phase. Every process step taken in a different environment reports back to the controller dashboard as soon as that process step is completed or when an error occurs. This ensures that the processes are perfectly aligned as there is one central controller controlling the entire process.  New actions can only be initiated from the controller dashboard. As a result decisions regarding the process flow to be followed can only be made from one central point, instead of having other systems performing consecutive actions and reporting back only after a number of actions have been completed.  Errors are immediately reported to the controller, which allows commencing error handling in a virtually online mode. "We in marketing are now completely responsible for the SIM card ordering management process," stresses the SIM card Product Manager. "Not only do we control the process input, we can also reconfigure it for new SIM card types. If anything, the innovated SPOMS process has put an end to the situation where the responsibility for errors was shunted back and forth between departments. With the SPOMS dashboard we can monitor the status of the outstanding orders in real time, and the system warns us immediately when there is a problem somewhere along the chain. Now, we can manage the entire process in a much more focused way."

Accomplishments: IT-Enabled Innovation Rewarded

The performance of the redesigned and automated process was reviewed in May 2009. Data gathered from January to April 2009 were compared with data collected over the same period in 2008. As the renewed SPOMS went live in October 2008, it was considered that enough time had elapsed to gain experience and further refine the process before starting the comparison. The old and new SPOMS were compared based on the following criteria:

Increased SIM card production capacity

The total number of SIM cards introduced onto the market after creation of a purchase order, has remained the same. The reason for this can be found in the market demand, which has slowed down because of the economic crisis. Nonetheless, we note that the process capacity has increased substantially.

The architectural approach provides for flexible up-and downscaling without any hassle. Development of new applications is far easier in service-oriented environments because these allow for flexible reuse of service components [START_REF] Weske | Business Process Management: Concepts, Languages, Architectures[END_REF].

Shorter lead time from purchase order creation until ready for delivery to the market

The lead time of the entire production process was reduced significantly. For every 100,000 SIM cards produced, 23 working days have been gained, i.e. a lead time reduction of approximately 1 month per 100,000 cards. This time saving is the result of a reduction of the time needed to develop and send the SIM card production request file to the SIM supplier. In the redesigned SPOMS no manual intervention is needed to create the request file, as opposed to the former SPOMS.

The Supply Chain Administrator can now give priority to marketing actions if needed. In 2008, for every preactivation a ticket had to be created for requesting this preactivation and time-consuming communication was needed in order to update the schedule. This has now been automated and centralized at the level of the process owner, who makes the decisions and manages the entire process. Next to the process optimization by the scheduler, also the capacity of the preactivation system has increased.

Shorter total lead time of marketing actions, from defining a new card layout until ready for delivery to the market

Given the shorter production lead time (see above), the total lead time is also considerably reduced. When considering the total lead time of marketing actions, we note that in 2008 a marketing action was initiated 3 months before the planned deadline, whereas in 2009 an action could still be approved until 6 weeks before the scheduled date. The reasons for this are the shorter production lead time on one the hand (reduction of 1 month), and the faster definition of the card, which is now a transparent process that can be carried out by means of master data creation, on the other hand.

Reduction of workload in the Supply Chain Department

Within the supply chain team an 80% reduction of FTE involvement in SPOMS has been realized, allowing FTEs to be reallocated to other activities in the department. Furthermore, the automation of the entire process has also significantly reduced the workload in all other departments involved, because the process is far less complex and error-prone than before.

In general, due to the shorter total lead time, Belgacom Mobile can respond much faster to market demands for promotional actions, which benefits overall competitiveness. Secondly, the internal stress level, caused by barely being able to meet the deadlines of a marketing action, has dropped noticeably. This is mainly the result of the shorter total lead time, which allows for a better planning and faster goto-market, smoother communication between all parties and reduced manual followup of actions.

Lessons Learned

Lesson 1: The Product Factory for Process Flexibility

During the reengineering project, some important lessons were learned that may prove valuable for future process reengineering projects. First of all, a major breakthrough was realized by separating product and process by means of the Product Factory concept. The key benefit of this approach is long-term process flexibility, which allows for product innovation without consequently having to change the process or having to install a new process. The reusability of the solution concept for other applications is another added bonus that comes with the application of SOA.

Lesson 2: Combining Process Thinking (BPM) and Architecture (SOA) for IT-enabled Process Innovation

Secondly, the SPOMS case at Belgacom clearly highlights the potential of a processoriented approach combined with architectural principles. The Logistics Manager comments: "This project has really convinced me of the importance of process thinking and architecting for this company. It was remarkable to see project participants ponder the impact of the decisions we made throughout the SPOMS project on other departments (even beyond the ones involved in the project) -which is quite unique. Some of this end-to-end thinking has led us to add additional peripheral processes to the original scope of the project." He adds: "Our choice for an architected approach has enabled us to unravel the enormous complexity of this business process. The investment in business process modeling has resulted in transparency, which helped us to make sure that we did not overlook any important aspects. The architectural approach we adopted provided the necessary scalability and flexibility. It did take almost a year to map all of the requirements, but this effort certainly paid off in terms of efficiency and sustainability."

Lesson 3: Project Management

In terms of project management the project lived up to the expectations. The scope remained virtually unchanged during the entire project, and the project was completed on time and even on budget. Critical to this success were the well formulated business requirements, the strong business case, and great collaboration between all of the parties involved. As the project sponsor, the Logistics Manager made sure that the initial project scope and architecture were not compromised by superfluous 'nice-tohaves'. The SIM card Product Manager testifies to this: "Indeed, from a marketing perspective we tend to push for more features all the time. But the project sponsor was always there to challenge the necessity of these extras from the viewpoint of the initial business case and verified if they really fitted within the solution architecture. This resulted in a solution that is highly efficient, but can still be leveraged for future use."

The IT Project Architect responsible for designing and implementing a solid technical solution, agrees: "This was one of these projects that was actually completed on time, on budget and without major scope adjustments. The fact that a sound business case and analysis were developed and carried out prior to the project launch really proved worthwhile. We knew why we were doing it and what we were getting ourselves into."

Conclusion

Over the years, Belgacom Mobile's market position has come under increasing pressure due to fierce competition and changing customer demands. As the Telco sector is highly turbulent and known for its fast technological advances, flexible people and processes are crucial for keeping up with the competition. For marketing purposes it is extremely important to be able to launch SIM card campaigns as quickly as possible. In addition, the risk of process failure may affect Belgacom Mobile's brand image and market position. The SIM card order management process is therefore a core process for Belgacom Mobile and its reliable functioning is therefore an asset to the company as a whole.

The Logistics Manager sums up the achievements of the SPOMS project: "We have put a lot of hard work in SPOMS. We have prepared exceptionally well with a very strong team of people combining different backgrounds. The result is a truly versatile and solid new business process supported by tools that enable the front-line staff to provide the efficiency and flexibility our markets require. This IT-enabled business process innovation is actually the result of a combination of end-to-end thinking, team work, results orientation and, last but not least, an architectural approach to support not just sustainability of a technical solution but also design freedom for product managers."

This paper contributes to the general understanding of combining an architectural approach with BPM in the frame of IT-enabled improvement projects. Managers gain a deeper insight into how process reengineering can enhance process flexibility and thus create room for product innovation generating benefits that go beyond mere internal efficiency gains. In general, due to the reduced total lead time, Belgacom Mobile can respond more quickly to market demands for promotional actions. This has strengthened the company's competitive position. In terms of project management, the SPOMS project stands out because it was completed on time and on budget, without major scope adjustments. Moreover, project insiders indicated a close collaboration between several business departments and the IT department as a key factor to the project's success. Ultimately, the new SPOMS process promises to deliver not only operational benefits, but also maximum process flexibility for new products to be introduced, which is one of the main drivers in the turbulent telecommunications sector. Furthermore, this case provides evidence of the business value of IT-enabled process innovation and BPM investments, a missing link in literature.

Fig. 2 .

 2 Fig. 2. IT impact on process innovation (adapted from[START_REF] Davenport | Process Innovation: Re-engineering Work Through Information Technology[END_REF]

Table 1 .

 1 Three IT purposes at Belgacom (Source: Presentation by Mr Scott Alcott, Executive VP Operations, Belgacom Group, 22/02/2010, [27])

Acknowledgements:

The authors wish to thank Belgacom Mobile executives Johan Verbeeck, Pascal Masuit, John-David Hendrickx, Scott Alcott and Laurent Claus for their valuable contributions to this work and for the possibility to look into this exceptional case. Furthermore we express our gratitude to Bert Van Genechten, a Delaware consultant.


Rogerio Atem De Carvalho

Fernando Luiz De Carvalho E Silva

Rodrigo Soares Manhães

Gabriel Lima De Oliveira

Implementing Behavior Driven Development in an Open Source ERP

Keywords: Behavior Driven Development, Automated Tests, ERP

A typical problem in Software Engineering is how to guarantee that all system's requirements are correctly implemented through source code. Traditionally, requirement tracing is a manual task comprised of keeping links from requirements to source code, going through different modeling artifacts, including models. However, these techniques cannot guarantee that requirements are always correctly implemented by source code. Aiming at solving this problem, Behavior-Driven Development (BDD) is a specification technique that automatically checks if all functional requirements are treated properly by source code through the connection of the textual description of requirements to automated tests. Given that for Enterprise Information Systems, requirements are usually identified by analyzing business process models, and these processes are implemented through workflows, connecting workflows to automated tests through BDD specifications can provide automated requirements traceability. The aim of this paper is to briefly present this proposal and show how it was implemented for the open source ERP5 system.

Introduction

Requirement tracing is a typical Software Engineering matter that can be described as how to guarantee that all functional requirements are implemented correctly by the source code. Many techniques were developed to address requirement tracing, such as the use of the Requirements Traceability Matrix [START_REF] Carlos | Requirements Traceability Matrix -RTM[END_REF], which keeps track of the source code elements that realize the requirements. These artifacts require that developers determine by hand, for each functional requirement, which classes collaborate to implement it. This technique is time consuming and error prone, given that the traceability work is done manually and through the introduction of an additional artifact -the matrix. The ideal way of keeping track of requirements is directly linking them to source code.

Behavior-Driven Development (BDD) [START_REF] North | Introducing Behavior-Driven Development[END_REF] is a specification technique that links functional requirements to source code, through the connection of the textual representation of the requirements to automated tests. BDD extends Test-Driven Development (TDD) [START_REF] Beck | Test-Driven Development by Example[END_REF], which in turn is a technique that consists of writing test cases for every programming task, before these implementations are performed. TDD is intended to achieve the correct solution that exactly matches the business problem at unit and integration levels [START_REF] Koskela | Test-Driven: TDD and Acceptance TDD for Java Developers[END_REF] -while BDD takes care of the acceptance level, where requirements reside.

For Enterprise Information Systems, identify requirements by analyzing business process models facilitates the participation of the domain experts [START_REF] Heinecke | Generating Test Plans for Acceptance Tests from UML Activity Diagrams[END_REF]. Business processes, in turn, are implemented through workflows. Therefore, connecting workflows to automated tests through BDD specifications can provide an end to end traceability of requirements, as well as facilitate communication among developers and domain experts. This paper aims at presenting the application of BDD to the Open Source ERP (FOS-ERP) ERP5 [START_REF] Smets-Solanes | ERP5: A Next-Generation[END_REF], as a way of showing how this technique can drive the development of high quality business systems. The proposal here presented is a simpler variation of the Business Language Driven Development (BLDD) technique [START_REF] Carvalho | Business Language Driven Development: Joining Business Process Models to Automated Tests[END_REF], which extends BDD by using business process models to drive the testing process. This paper is organized as follows: after this introduction, BDD main characteristics are briefly presented; followed by the description of the application of it to ERP5, and finally conclusive remarks are commented.

Introducing BDD

BDD starts by defining requirements using specific keywords that tag the type of the sentence, indicating how it is going to be treated in the subsequent development phases. These descriptions are written in an Ubiquitous Language (UL), which is a language structured around the domain model and used by all team members to connect all the activities of the team with the software [START_REF] Evans | Domain-Driven Design -Tackling Complexity in the Heart of Software[END_REF]. In summary, requirements are described sets of Given-When-Then constructs (GWT) [START_REF]Behavior Driven Development[END_REF]: Given a Context (or a system State) When an Event happens (or an user Action) Then an Action is taken (or a system Reaction)

From this point onwards, a story runner maps the natural language sentences into the underlying programming language equivalent calls, while keeping the same abstraction level. The next step is to write acceptance tests to the generated steps, pieces of code that excite the source code that implements the system. By wrapping all implementation code with tests, which in turn are automatically tied to the business requirements using the GWT constructs, the need for requirement documentation is fulfilled, having the advantage of making the whole system verifiable automatically at any time. Therefore, the use of BDD allows reducing the risks and effort to implement a given change in an information system; hence the system can be continuously improved without making the cost of change grow exponentially, avoiding Boehm's Cost of Change Curve phenomena [START_REF] Carvalho | Agile Software Development for Customizing ERPs[END_REF]. Moreover, the Then constructs represent the tests' acceptance criteria, stating an objective method to validate if a given requirement is done.

According to [START_REF] Carvalho | Business Language Driven Development: Joining Business Process Models to Automated Tests[END_REF], BDD provides an automated and cost effective way of keeping requirements traceability, addressing each of the challenges introduced by Kannenberg and Saiedian [START_REF] Kannenberg | Why Software Requirements Traceability Remains a Challenge[END_REF]:

-Cost: it is able to provide full tracing in a way that is even cheaper than Value-based requirement tracing [START_REF] Heindl | A Case Study on Value-Based Requirements Tracing[END_REF]. Requirements are tied to tests, so that if tests return nonexpected values or simply are not implemented, the tool will automatically point out the problem. -Managing change: there is no need to impose "strong discipline in maintaining the accuracy of traceability", instead, BDD tools make all the necessary checks automatically. Whenever a requirement changes, the tests will not run until the code is also changed accordingly. Moreover, by changing a requirement and immediately running a complete build, errors will pop-up in specific places where the system must be changed, easing effort estimation.

-Different stakeholder viewpoints: standards provide no guidance to traceability [START_REF] Kannenberg | Why Software Requirements Traceability Remains a Challenge[END_REF], through BDD, it is possible for any stakeholder to check system consistency, since it is based on executable documentation. Even end users can push a button and check its higher level error messages.

-Organizational problems: according to [START_REF] Kannenberg | Why Software Requirements Traceability Remains a Challenge[END_REF], "the easiest way to correct organizational problems related to traceability is through the use of policy and training". BDD provides a proper policy for traceability because it enforces the connection between code and requirements.

-Poor tool support: the correct combination and use of BDD and TDD testing tools results in a development environment which monitors and alerts about inconsistencies introduced in the code.

BDD in ERP5

ERP5 is an open source ERP that offers an enterprise-wide system based on the open source Zope platform. This platform integrates an object database, a workflow engine, a content management framework, and rapid GUI scripting [START_REF] Smets-Solanes | ERP5: A Next-Generation[END_REF]. ERP5 has different variants for industry, governments, and services, including CRM, MRP, SCM, Sales, Payroll, and others modules.

The motivation to use BDD in an ERP that works on top of a workflow engine is to connect tests directly to the workflows, thus joining the business logic represented by the workflows to the requirements comprehension represented by automated tests, or, in other words, checking the validity of the mapping from the business experts' definitions to the developers' definitions.

The first step to use BDD in ERP5 was to map GWT constructs to state-based business process models, given that ERP5's workflow engine is state-based. This task was facilitated by the fact that GWT constructs represent a state machine, connecting the human concept of cause and effect, to the software concept of input-processoutput. According to [START_REF] Martin | The Truth About BDD[END_REF], this convention "is simply a state transition, and that BDD is really just a way to describe a finite state machine. Clearly Given is the current state of the system to be explored, When describes an event or stimulus to that system, and Then describes the resulting state of the system." Therefore, the set of all scenarios of a given business requirement can be represented by a Finite State Machine.

Following this reasoning, and using the mappings from the most common business process patterns to GWT constructs provided by [START_REF] Carvalho | Mapping Business Process Modeling constructs to Behavior Driven Development Ubiquitous Language[END_REF], it was developed an ERP5 module which connects the system's workflows to their automated tests through detailed definitions described using GWT.

The sequence of steps for using the Feature Module for implementing a given business process is as follows: a) Represent the business process in the system using a state-based workflow. b) Describe the feature's goal and its business value. c) Define each scenario (state change) supplying examples. d) Using the values defined in the Given and When clauses, write the automated tests. Tests success will be checked by comparing their results to the acceptance criteria defined in the Then tags. e) Write the source code that implements the workflow, and that will be excited by the tests. f) Run the tests and check for their correctness. In order to exemplify this process, the ERP5's Basic Sale Opportunity business process, showed in Fig. 1, is used. Fig. 2 shows the Module's main form used to describe the feature, as well as to list its scenarios. Features are described for the sake of defining their business value. The arrow in the figure indicates the icon to create a new scenario. Following BDD's incremental and test-first process, the following sequence of steps is performed for each state change on the workflow: (i) create a scenario defining the example values for the tests and the acceptance criteria, (ii) write automated acceptance tests, (iii) write the equivalent source code, (iv) run the tests until there are successful. In order to support this incremental process, the Feature Module allows the execution of each scenario independently. The result of running the scenario "Sale Opportunity is Submitted" is shown in Fig. 3. The first four lines prepare the environment for the test, creating the workflow object, while the fifth and the sixth lines are responsible, respectively, for firing the transition, and checking if the workflow is in the expected statesubmitted. After defining all scenarios, it is possible to run the workflow's different paths. Fig. 4 shows the "happy path" of the sale opportunity, ending in the sold state. 5 shows what happens if the test fails for a given scenario, for demonstration purposes, a wrong expected state called "not enquired" was used as acceptance criterion, while the source code changes the state to "enquired", raising an assertion error. In that way it is possible to identify which specific part of the workflow is not in accordance to the acceptance criteria, and even a business expert can identify what is the problem by checking the test log. If other errors were present they would be raised one by one.

Although the workflow logic already provides, by nature, the current state (Given), the event and its conditions (When), and the new state (Then), the textual representation of the workflow provided by the GWT constructs is necessary for two reasons: (i) provide example values for the automated texts and (ii) describe internal changes in the information system, such as the creation of objects.

Conclusions

This paper aimed at briefly presenting the first implementation of the BDD technique into an ERP, in this case, the open source ERP5. Moreover, it showed an ERP5 module specifically developed to integrate the BDD's features with ERP5's workflows. In that way, the goal of joining the advantages of using BDD to keep track of all requirements while using an underlying workflow engine was reached.

A future direction is making the Feature Module able of, by checking a given workflow's configuration, generating the GWT constructs, guaranteeing that all transitions will be implemented. By changing the generation of GWT constructs to a specific language that reflects a state-based workflow, as proposed by [START_REF] Carvalho | Business Language Driven Development: Joining Business Process Models to Automated Tests[END_REF], it is possible to use a single a unique language for describing both business process and testing details.

Fig 1 .

 1 Fig 1.: ERP5's Basic Sales Opportunity process.

Fig 2 .

 2 Fig 2. Creating the Feature and defining its value.

Fig. 3

 3 Fig. 3 Results of running the scenario "Sale Opportunity is Submitted." The red arrow marks the firing of the transition and the checking of the workflow state.

Fig. 4

 4 Fig. 4 Sales opportunity's happy path tests successfully ran.

Fig.

  Fig.5shows what happens if the test fails for a given scenario, for demonstration purposes, a wrong expected state called "not enquired" was used as acceptance criterion, while the source code changes the state to "enquired", raising an assertion error. In that way it is possible to identify which specific part of the workflow is not in accordance to the acceptance criteria, and even a business expert can identify what is the problem by checking the test log. If other errors were present they would be raised one by one.Although the workflow logic already provides, by nature, the current state (Given), the event and its conditions (When), and the new state (Then), the textual representation of the workflow provided by the GWT constructs is necessary for two reasons: (i) provide example values for the automated texts and (ii) describe internal changes in the information system, such as the creation of objects.

Fig. 5

 5 Fig. 5 Test failed while trying to transit to a wrong state.


Adnan Kraljić
email: akraljic@ibu.edu.ba

Tarik Kraljić
email: tkraljic@ibu.edu.ba

Denis Delismajlović
email: ddelismajlovic@ibu.edu.ba

Adoption of Standard ERP Solution in Health Care Sector: Is SAP ERP All-in-One Capable to Meet Specific Requirements?

Keywords: SAP ERP All-in-One, Health care information systems, Inventory management, Health care billing system

Objective of this experience report is to address specific issues regarding standard SAP ERP implementation in a medical institution. Target Company is a state owned health care institution from Bosnia and Herzegovina. Report will treat selected issues which could trouble standard SAP ERP implementation trough predefined ERP implementation methodology for SAP ERP. This report presents observations/remarks based on experience of authors in particular SAP ERP implementation project in health care institution. Author's goal is to provide useful insight into "real life" standard ERP implementation and problems that arise. Also, it should provide useful information for all stakeholders involved in the process of ERP implementation in public health care sector.

Introduction

This industry report provides insight into an implementation of SAP ERP solution in a major medical institution in Bosnia and Herzegovina with several thousands of employees. The project was initiated by management of the hospital with purpose to eliminate the ineffectiveness of the current information system. Analysis of the current financial system and the list of new system requirements have been prepared by an external consulting company. This was required for announcing a public tender for selection of the ERP software solution integrator. After several months of tender procedure and assessment of the best vendor (price was eliminatory criteria, in accordance with the law), software integrator was selected. At the end, SAP All-in-One solution [START_REF]SAP Business All-in-One[END_REF] was the preferred one. Relevant project information is presented in next sections.

As recommended by external consultants the main goals of the project were:  To centralize the information system (create/provide a centralized database);  To increase data integrity and consistency;  To focus on accounting and financial department processes;  To improve drug warehouse management and billing system;  To provide comprehensive and accurate reports for top management;

The project incorporated five SAP modules: FI (Finance), CO (Controlling), MM (Material management), SD (Sales and Distribution) and HR (Human resources). SAP integrator offered a team of seven SAP solution consultants, including one SAP system administrator. In addition, two consultants (ABAP programmers) were teamed up for specific ABAP developments. During the implementation it became clear that the number of consultant was inadequate, given the project scope and specific demands in medical service industry.

Situation before SAP implementation

The hospital is an institution that devotes considerable resources in upgrading its primary domain and activities by investing in specialized diagnostic and medical equipment. However, this is not the case with ICT. No substantial investments were made in information system improvements in the last twenty years. Moreover, parts of existing hospital IT infrastructure were damaged during the war (1992)(1993)(1994)(1995).The example which reflects this initial situation is that network between Clinics was nonexistent of network infrastructure between Clinics which is the basic assumption for any SAP implementation Due to the law regulations, the hospital was obliged to have certain software solutions, mainly disintegrated applications aimed at specific business domain. This software landscape contained dozen applications developed by one or few individuals. There was no recognized company behind them. All applications were technically isolated instances, mostly installed only on local machines with no server-client architecture. All master and transactional data were stored on a single machine. Only network connected application was accounting (General ledger) application (terminals), which was implemented in the eighties. The final (consolidated) reports, made by manual data collecting from various applications, were presented to the steering committee. The process of preparing reports took between five to ten days. Microsoft Excel sheets were being (physically on USB) passed from department to department. The most representative example of their legacy IT architecture was the billing system. Each PC machine had application installed for specific billing types (7 types/scenarios of billing); there were seven local machines each responsible for the specific billing scenario.

The implemented system was standard SAP ERP All-in-One. Since it was not specialized health care solution, additional industry-specific functionalities needed to be developed to fulfill basic client's needs. They were mostly related to the processes of Materials Management and Sales and Distribution.

In the following sections we will discuss main issues faced during SAP ERP implementation in two mentioned modules: MM (Materials Management) and (Sales and Distribution).

Sales and Distribution functionality and obstacles

Standard functionalities of SAP ERP SD include handling of sales and distribution. The main activities are the sales order handling, and the distribution of shipments to customers. In addition the billing process, customer invoice, delivery, and risk management are responsibility of the SD module. The Sales and Distribution (SAP SD) consists of all master data, system configuration, and transactions to complete the Order. The billing process is important for every Health Institution, hence it was recognized that SD module is necessary to be installed in the hospital.

Particular attention was paid on the billing department which bills all medical and non-medical services provided by the institution. Billing department employs of 20 people, who create over 15 000 invoice documents (billing documents) each month. This number of invoices does not pose a problem for SAP SD module. The real issue was the complexity of the invoicing process. As the previous billing software was outdated, complex billing affected process of collecting receivables negatively, as billing department was constantly in delay of two months when invoicing services provided to patient.

The process of invoicing can be divided into three stages, as shown in the Figure 1:

1. Specification of healcare service provided 2. Run a settlement of specification for every patient 3. Create a billing document according to settlement

Billing document Start

Fig. 1. Process of invoicing in the hospital

All processes shown in the diagram above were conducted in separate programs (software). This meant that for each operation, point cleric was required to re-enter data. The reliability of information over this life cycle was not guaranteed as the process was manual. In addition, billing of health services was carried out separately for different types / groups of patients; 7 types in total. All these different types have a special logic of calculation for health services, which was necessary to be realized and implemented through the implementation of the SAP SD module.

Issues and problems arose during SAP SD implementation:

a) The first detected problem was that the standard SAP system does not contain functionalities which would adequately handle the first process in billing system's life cycle -creation of specifications for health services provided to a patient. The suggestion given by SD consultants was not implementing this particular process with SAP system, and leaving it for the eventual second phase of the project, which was the implementation of the full SAP Healthcare solution. This suggestion was rejected by the steering committee. The decision was to develop this functionality using ABAP programming. . Add-on for standard SAP SD module had to be made, which would cause a number of changes in core SD processes (sales orders creation and billing documents creation).

At first, decision seemed reasonable, but later it proved to be one of the biggest mistakes made by SAP project manager. This generated other problems, such as dramatic increase in number of new users and SAP licenses needed for employees who would work on the data input for specification of health services and billing. It became apparent that the project cost was very close to violate the budget. b) Another big issue raised was that the process of specification orders of healthcare services and pricing calculation was not standardized. The procedures and rules for price calculation differed between the clinics, so there were over 10 "QS procedures" which greatly hampered the first phase of SAP project -creation of Blueprints. Blueprint phase, which was planned to last for maximum of one month, was extended to a 80 days, due to unsynchronized billing processes and defined billing procedures in the hospital (once again -each clinic has its own procedure). Also, each clinic has its own working practice, which put additional strain on system integrator. Although the Blueprints phase represents the very first phase of the SAP project according to the ASAP methodology, it was clear that the period of 4 months for full implementation and go live were insufficient. All of this put enormous pressure on consultants.

c) The process of master data migration, and import preparation on the test system, discovered a lot of irregularities of the previous billing system procedure. It was possible for the same patient to have four different codes (system ID) depending on the type of service for which he was billed.

By the end of the project, along the standard ones, the following non-standard functionalities were implemented (developed as add-on):

1. Creation of specification of healthcare services (two type and transactionsfor ambulant and hospital use); 2. Creation of advance payment for hospital and ambulant use; 3. Automated process for creation of sales order referenced on healthcare specification; 4. Automation of price calculation depending on a patient's status; 5. Development of many Z reports (add on development on standard SAP).

Material Management functionality and obstacles

From the beginning of the project it was apparent that the drug warehouse of the hospital will be the most demanding part of the whole project. With annual turnover around 40 million EUR it was the major consumer of the hospital's budget. New, efficient inventory management system was essential to the "profitability" of the drug warehouse.

SAP ERP All-in-One was chosen to replace the old legacy system that was in use. This existing system was specifically designed and developed for the drug warehouse with features adjusted to their specific needs. The system was in use for over 12 years and was improved/upgraded during this time. However, the system operated only in this organizational unit. At the end of each month, accounting department was provided with the reports (goods receipt, goods issue, goods transfer, inventory status etc.) from the system, which contained no detailed analytics in itself.

The SAP module which covers processes of clinical drug warehouse is called SAP MM (Material management) module. All the issues that standard SAP MM module faces during implementation phase are stated in the rest of this section. a) Adequate inventory is generally defined as basic stock plus safety stock. Inventory which is to big is a leading cause for unsatisfactory cash flow. On regular basis, hospital's drugstore had to put more of its cash into the purchase of medicaments in order to meet its obligations, especially in the case of the wholesaler who was located outside of Bosnia and Herzegovina. In theory, SAP ERP All-in-One solution provides the MRP function which covers the safety stock. The idea is to alert the responsible person when a group of materials or a material is close to the minimum of inventory stock, and suggest the number of units that should be purchased in order to meet the optimal stock. However, in practice, system provided alerts only when the responsible employee wanted to order particular material. Unfortunately, it was possible that the material is already under the safety stock red line. This was frustration for both, SAP consultants, and hospital warehouse management.

b) The complete database of pharmacy's inventory needed to be implemented according to the generic molecules, as it ensures standardization across health systems.

c) Even though it was not defined in the scope of the project, it was necessary to fulfill all pharmacy standards regarding pharmacy business proposed by law. All generics & their particular brands, batches, used by the hospital had to be maintained in a database with the appropriate commercial terms (commercial name, pharmacy agency approval number etc). At first, the main challenge for the SAP integrator and consultants was implementation of ATC/DDD standardization for medicaments. The ATC/DDD system classifies all therapeutic drugs and provides a tool for drug utilization research in order to improve quality of drug use. In the ATC classification system, drugs are divided into different groups according to the organ or the system on which they act and their chemical, pharmacological and therapeutic properties. Drugs are classified into 14 main groups / classes [START_REF]WHO: The Anatomical Therapeutic Chemical Classification System with Defined Daily Doses (ATC/DDD)[END_REF], [START_REF]Anatomical Therapeutic Chemical Classification System[END_REF]. Each of the main classes contains hundreds of subgroups which include hundreds of groups itself. At the end, there was a need for thousands of predefined material groups in SAP MM. This approach was overly complicated so the integrator decided to implement the SAP Classification system for clinic drug warehouse.

The Classification system in SAP for clinical drug warehouse was, at the beginning, seen as blueprint of ATC/DDD classification. However, implementation/situation became more complex. The Classification system in SAP does not only depend on the definition of the ATC/DDD, but also on costing procedures and reporting (which was wanted to get as reports from classification). In addition, assuming that SAP classification needs to meet all, by law, proposed legislation, SAP integrator defined set of characteristics for each material. After few kick off meetings integrator came up with those classification characteristics; presentation/package (box, pills, mg etc.), aggregate state, product hierarchy grouping (ATC/DDD) and profit centers. All of these had to be set as characteristics of the material classification. After months of preparation of all materials (over 30 000 records) for import into the system with all the necessary classification characteristics, it became apparent that such a big number of characteristics would be hard to maintain. Performance of drugstore as whole was seriously jeopardized by the time required to complete the entire process of maintaining material master data. At the end, this SAP classification system was refused by the hospital's drugstore.

d)

The lack of batch management and shelf life -The main and very important point of any drug warehouse is the batch management. All pharmacy products are managed by the batch and the shelf life. Those are critical factors for managing the inventory efficiently. The standard SAP ERP provides fields (after activation) for those material attributes, but, once again, it did not work properly in practice. The standard SAP ERP does not provide ad-hoc integration of bar code reader technology, so the only option was to extend the project's scope and to develop the specific solution for bar code technology. Moreover, integrator was required to build up good receipt transaction in SAP (MIGO transaction) in order to support goods receipt process supported by code readers. This particular development increased the project's costs.

Another issue was the shelf life of materials. The proposition from hospital drug warehouse management was to create inventory management system where medicaments with closest expire date would be suggested for goods issue. However, this was not a feature of the standard SAP ERP All-in-One. It was only possible to create a new report where all medicaments would be listed by the expiry date criteria. However, this was not satisfactory for clinical drug management because their employees required too much time to operate with particular report. e) Standardization hierarchy for equipment (medical as well as non-medical) -The complete database of non-pharmacy inventory like equipment, linen, stationary, sundry items etc. was imported in SAP. Also, the database of the approved suppliers for each item was maintained with relevant commercial terms & specifications. However, as with the ATC/DDD standardization, the proposed solution for standardization of the equipment (class/subclass/group) was impractical for daily usage.

f) Goods issue of material was not linked to the specification of healthcare services for a patient (SAP SD module) -One of the major issues for the SAP integrator was implementation of fully automated goods issue process. At the beginning the idea was to blueprint the real life scenario. That is, medicament was supposed to be issued when given to patient. However, in reality, due to the lack of infrastructure (no available network) and because of the license issue (management of clinic found it too expensive SAP), process was delayed 7 days at average. So, medicament was issued to a patient from the department drug storage location, but transaction was written on a paper. After 7 days, when the list of medicaments issued is usually over 50 pages long, it is provided to employees in central hospital drugstore, and then imported into SAP. This was undesirable process for employees who import those lists weekly into SAP. In addition, dozens of mistake were made each week due to manual data import into SAP system.

Conclusion

Implementation of the standard SAP system in health care environment results in specific issues and problems during the implementation of SAP ERP SD and MM modules. The main problems encountered explained for SD and MM module are:  Standard SAP SD module does not fit health care institution billing needstoo much development is needed, which is not good for maintenance and support;  SAP ERP SD is not intended to cope with patient master date (huge load of data);  The Standard material group in MM is not sufficient to describe ATC/DDD standardization;  SAP material classification is too complex when it respects all attributes needed for maintaining drug material master data.

This leads to the general conclusions regarding implementation of standard SAP system in health care institution:  Standard SAP ERP system does not support specific Healthcare processes, so a lot of custom development (i.e. "Z" programs) must be made to fulfill customer's requirements. It is a risky decision, because it boosts system maintenance cost;  SAP All-in-One is not capable to meet all the health care institution requirements in a satisfactory way without SAP Healthcare solution, i.e. SAP ERP is tailored to fit standard business processes present in majority of business domains. However, only SAP Healthcare industry specific solution addresses all specific requirements for healthcare institution.