0-SUPPORT FOR CHANGE MANAGEMENT DURING BPMS IMPLEMENTATION USING AN OPEN SOURCE APPROACH

The authors argue that business process management systems (BPMS) are exposed to similar risks of failure as are traditional enterprise resource planning (ERP) systems. Change management is a significant critical success factor, and has to be managed well. Given the socio-technical nature of the implementation environment, communication and collaboration are crucially important to the success of change management. The authors provide an example of how collaboration and communication, as part of change management during BPMS implementation, can be achieved in practice, based on the use of Web 2.0 tools and an open source approach.


INTRODUCTION
Business process management has seen a revival in the past few years with the rise of business process management systems (BPMS).A typical definition of BPM [1] would be that BPM is an IT-enabled management discipline that requires organisations to move to processcentric thinking and reduces reliance on traditional functional structures or silos.Hayward [1] extends the definition to include the business process lifecycle, from process design to monitoring and optimisation, as the scope of BPM projects.The process lifecycle contains key elements that are addressed by BPMS solutions.
Burlton [2]argues that hyper-competition, growing organisational complexity and reach, rising external stakeholder power, and e-business technology are the major forces that drive organisations to revisit business processes.Hyper-competition is fuelled by shrinking business cycles, commoditisation of products and services, and the provision of knowledge as a product or service.This requires organisations to be agile in their approach to business processes, and to have the ability to react to changing market conditions.BPM focuses on differentiating organisations through their processes and driving operational efficiency.Typically, organisations have two or three processes that differentiate them completely (core processes).While the remaining processes may not differentiate them, theymay still be mission critical in supporting the business (commodity processes) [3].All processes require high levels of agility and flexibility to adjust to business and market conditions.This is achieved through the deployment of BPMS.The objective of a BPMS in support of BPM is to use technology to create executable processes with business rules and embeddedhuman knowledge.

The similarities between BPMS and other enterprise systems
Business process management systems (BPMS) have only recently been recognised as enterprise systems [4], and the influence within the IT domain of systems such as enterprise resource planning (ERP) and workflow management (WFM) systems on the conceptualisation of BPMS has been explicitly recognised [5].The new generation BPMS therefore exhibit significant similarities to other enterprise systems (such as ERP systems).The first similarity pertains toenterprise systems that present an integrated view of the enterprise from a single 'source' [6].BPMS in enterprises have been increasingly 'scaled up' to reflect processes at an enterprise level rather than as a once-off exercise, and BPMS technologies are integrated (i.e.single source equivalent [7]).The enterprise 'toolset' presented by BPMS is used to manage business processes throughout the BPM lifecycle.The BPM lifecycle could be defined as: define, model, simulate, deploy, execute, monitor, analyse, and optimise [8].Second,enterprise systemsare focused on changing the organisation [6]; while BPMS have similar capabilities [7].A third similarity concerns organisational changes that are intimately linked to successful changes in organisational business processes, in the case of both ERPs [9][10] [11] and BPMSs.The fourth comparable characteristic relates to the socio-technical nature of both process modelling and ERP implementations, i.e. the business should take explicit account of the social aspects of change associated with technology implementations [12].For BPMS,human participation is of the essence at all levels of the organisation, and the role-player notion has been expanded from 'user' to 'social actor' and 'stakeholder' to emphasise the more expanded expectation of human participation [13].Also, in BPMSs the technical systems are joined to the business processes through the wider socio-technical systems in an organisation [14].The last similarity of relevance is thedepth and complexity of all the integrated activities (in the case of ERP) [15], and integrated processes (for BPMS), which can only be understood once the project is completed.

Similarity in fail factors between BPMS and other enterprise systems
Of specific interest to this paper is the similarity of fail factors and critical success factors for both types of systems, and notably the importance of change management.The technology, management, human, and process 'fail factors' for BPMSs that Reijers [16] identified (mainly related to a 'process orientation') are similar to those identified in the history of enterprise system failures [17].The characteristics shared by ERP solutions and BPMS applications would indicate that BPMSs should subscribe to the same critical success factors as conventional enterprise systems.More specifically, Trkman [18] highlights the importance of change management as a critical success factor for BPMS implementation.This is similar to the finding by Finney &Corbett [19] that change management ranked with top management commitment and support as the most significant of the critical success factors for enterprise systems in general.

BPMS implementation and its challenges
A significant challenge is the fast adoption rate of BPMS, which leaves BPMS implementers limited time to establish successful implementation methodologies [20].
It has been argued that the discipline of business process management can learn much from related disciplines about handling disruptions [21].We extend this to argue that, given the similarities between BPMS and other enterprise systems, it is also beneficial to learn from previous experiences on related enterprise systems.The dimension of failed implementation of enterprise systems such as ERP in comparison with BPMS has been particularly extensively researched,and therefore provides many insights that could enhance insights into BPMS implementation practices.
Enterprise system implementations are not always successful,due mainly to complexity factors [22].These include (1) the number and diversity of stakeholders; (2) the high cost of implementation and reliance on consultancy; (3) process integration across business units; (4) custom configuration of software that represents core processes; (5) change management requirements and political issues; and (6) extensive training and familiarisation requirements.Aspects of these failures have been comprehensively researched ( [23], [19], [24], [25], [26]).Complete failures include projects where the implementation was abandoned before completion, or where organisations suffered significant financial losses from the enterprise system implementation failure.Partial failures resulted in disruption in daily operations and 'tenuous adjustment processes for the company' [27].Similarly Robey et al. [28] found that enterprise systems often have significant budget overruns, and estimate that up to 50% of these projects fail to achieve the anticipated benefits because managers underestimate the change management requirements.
The extensive literature on enterprise systems such as ERP and CRM shows that the major critical success factor (after top management) is effective change management.We discuss how the crucial aspects of collaboration and communication as part of change management can be enhanced through the use of Web 2.0 technologies,increasing the possibility of success during a BPMS implementation.We additionally argue that adoption of an open source perspective -one that guides the principles underlying the processes and structures for collaboration and communication as part of change management -provides an innovative approach to reducing the risk of BPMS implementation failure.We demonstrate an example of a conceptual model that could achieve this in practice.

Structure of paper
The paper covers the following aspects: (1) change management for enterprise systems implementation; (2) the current state of Web 2.0 collaboration technology; (3) open source informing change management, collaboration, and communication; and (4) a proposed example of how Web 2.0 tools could be used in deploying a business process management suite.

Issues related to change management
Significant changes, such as the introduction of a BPMS, create uncertainty in the workplace.
In the light of the previously-stated socio-technical link between BPMS and BPM, the impact of implementing BPMS can be expected to be largely social, political, and personal rather than solely technical.BPMS is likely to suffer the same resistance to change as other enterprise systems.Kreitner and Kinicki [29] detail reasons for employee resistance to change: (1) a personal predisposition against change; (2) fear of the unknown; (3) an organisational climate of distrust; (4) lack of confidence; (5) loss of status or job security; (6) group power and peer pressure; (7) disruption of cultural traditions or group relationships; (7) personality-based conflicts; (8) lack of tact or poor timing; and (9) nonreinforcing reward systems.
These can be overcome through a variety of strategies, such as (1) education and communication; (2) participation and involvement; (3) facilitation and support; (4) negotiation and agreement; (5) manipulation and co-optation; or (6) coercion, depending on the situation within the organisation [29].Klein [30] highlights the importance of publicising successes during the various stages of a change management process.Provision of mechanisms for feedback and rectifying problems are equally important.
Communication is explicitly recognised as being crucial to successful BPMS implementation [5].Developing a communications framework for BPMS change management requires that certain communications goals are achieved with such a framework.Barrett [31] provides some guidelines for the communication goals of an enterprise systems implementation project: (1) clear and consistent messages on the vision and objectives of the project and on participant benefits; (2) motivation for employee support for envisaged changes; (3) encouragement of increased performance and discretionary efforts; (4) limiting of misunderstandings and rumours; and (5) alignment of employees with project strategic and performance improvement goals.Barrett lists targeted messages (information for a specific audience) as a key practice in the communications requirements for effective change.Edwards and Sridhar [32] also highlight the importance of coherently-structured task responsibility, and Ke and Wei [33] highlight the importance of participatory decision making during enterprise systems implementation.
Implementing a BPMS ultimately has to satisfy the overall business objectives.Seen from this perspective, the objective of using Web 2.0 collaboration technology is to assist with change management in enterprise systems implementation -which implies that IT is used as a driver of organisational change.Implementing a collaboration solution will have its own change management requirements, even if it is a catalyst to support change management for other projects.
Markus [34] argues that conventional change management is not sufficient, as it does not address the unique requirements of IT-driven change.The expectations from implementing an enterprise system are focused on producing significant improvements to organisational performance that are generally defined in organisational goals and corporate metrics.In this situation, the model for change has to accommodate a process of on-going and iterative experimentation, use, and learning [15].
Another challenge relates to the effect of 'time and distance' [34].The implementation of large-scale enterprise systems often requires that certain individuals (subject and domain experts) are removed from their day-to-day functions and placed in an isolated project team for extended periods.Absence from peer groups often creates resistance in other employees in the organisation to accepting changes to their processes and systems, even where these may substantially benefit them.
The existence of shared beliefs about the application and value of a particular enterprise system is significant for adoption [35].This warrants consideration of a collaborative approach that enables the management and communication of beliefs about the usefulness of the new system.Orlikowski and Hofman [15] state that an ideal change management approach for a groupware type enterprise system should be based on iterative experimentation and learning, which requires higher levels of communication and collaboration.Szamosi and Duxbury [36] found that communication of change is a critical component ineffective organisational change management.
It is clear that managing change for enterprise system implementation -specifically where new technology is deployed -is complex and challenging.It consists not only of technological change factors, but also includes perceptions, attitudes, and learning through iterative experimentation and use.This highlights the need for effective communication and collaboration.
A collaborative and communicative approach to change could include employees in the process design, thus limiting the surprise factor, minimising distrust, limiting the fear of failure, and leveraging the power of groups and peers.The objective of the collaboration process would be not only to address teamwork issues, but also to ensure that knowledge is created, shared, and maintained as part of the process.

Implications for collaboration and communication during BPMS implementation using Web 2.0 tools
Communication and collaboration are critical success factors for change (as discussed above) in relation to the use of new network technologies.Web 2.0 technologies can improve both internal and external communication capabilities in an organisation through informal communication across organisational barriers, and enhance innovation for large dispersed groups [37].Yamauchi et al. [38] caution that, even though electronic media eliminates spatial and temporal boundaries, it does have limitations compared with face-toface collaboration.Electronic media do not convey social characteristics well (e.g.anger, anticipation, or friendliness).They are often ambiguous or unclear, and can be easily misunderstood.Participation through getting people involved remains the key challenge.
There is evidence that Web 2.0 (or its organisational equivalent, Enterprise 2.0) does improve collaboration in large organisations.Murphy and Salomone [39] present three case studies of large organisations that have had success in this regard.However, Chui et al. [40] argue, based on a study of 50 organisations that use Web 2.0, that successful adoption does depend on participation by both management and users, integration with workflow, and the nature of incentives.

Teamwork, trust, and structures in virtual teams
The concept of virtual teams is central to the Web 2.0 collaboration solutions.Even though team members may not be geographically dispersed, functional silos or hierarchies in organisations create their own segregation, and it is not always feasible to get subject matter experts and contributors from various business areas into a single venue.The virtual teams' setup requires a shared space to record and review ideas, store artefacts, and communicate.Knowledge sharing among virtual teams is one of the key success factors of this organisational form and one of the reasons why some open source collaborative projects are highly successful.
Edwards and Shridar [41] found that, given a suitable environment, it is possible to promote a good level of trust between virtual teams.They also found that well-structured projects need to affect the outcome of virtual team collaboration positively.A Web 2.0 solution should thus recognise teamwork, trust, and structure with clearly identified roles as key components for an effective solution.
The objective of knowledge networks is to allow participants to create, share, and use various categories of knowledge artefacts using technology that is easy to use.
Ahn et al. [42] argue that contextual information is becoming increasingly important in the broader knowledge management paradigm.This also holds true for implementation of an enterprise system, especially in virtual environments.The reasons include (1) loss of contextual information in dynamic changes due to the temporal nature of virtual teams; (2) narrow communication channels via the Internet; and (3) the non-routine and knowledgeintensive nature of virtual team tasks.
The challenge in implementing an enterprise system is therefore effectively to turn tacit knowledge into explicit knowledge that is shared among all participants.The open source community is one of the leading groups to have created mechanisms to do this successfully.

THE CURRENT STATE OF WEB 2.0 COLLABORATIVE TECHNOLOGY
This section specifically focuses on the development of Web 2.0and on its components such as wikis, blogs, and RSS feeds that are applicable to the development of a collaborative solution to support change management during BPMS implementation.

The development of Web 2.0
In Web 2.0 the Internet is conceptualised as an application platform to deliver solutions and services rather than simply as a technology infrastructure.Hinchcliffe [43]  The use of Web 2.0 in the enterprise is often referred to as Enterprise 2.0, where the collaborative approach and tools of Web 2.0 are used in a business environment.Enterprise 2.0 focuses on those platforms that can be used by organisations to make visible the practices and output of the knowledge workers [44].
The objective is to distribute information more efficiently and to get employees to contribute and create the information.One of the principles of Enterprise 2.0 is that it does not have a position on an organisational chart, and should not suffer from bureaucratic control.(This is, however, a characteristic of the culture of the organisation, and requires top management support.) McAfee [44] highlights that Enterprise 2.0 implementations still require a structured approach.This includes several critical success factors: a receptive culture, a common platform, an informal roll-out, and managerial support.
Common components of Web 2.0 that are used in the deployment of enterprise applications could include wikis, blogs, RSS feeds, Mashups, instant messaging, and possibly social networking.The following sections will describe some of these tools in more detail, with a particular focus on how to use these tools in the development of a collaboration model to support change management.

Wikis
Augar et al. [45] define 'wikis' as fully editable websites where visitors can read, reorganise, and update its structure and content, which includes text and pictures, using a web browser.Louridas [46] extends the definition to software that makes it easy for anyone to edit web sites, and to a philosophy about how users should edit these websites.A wiki is unusual in that it allows both the organisation of contributions and the content itself to be edited [47].
Much of the information and content required during an enterprise systems implementation project is created by non-technical users.The objective of a collaboration solution would be to assist these users to organise information and content to the specific requirements of the project.A key principle of a wiki [46] is that these edits are visible to all users, and the identity of the editor is displayed with the changed content.Incorrect content is generally very quickly corrected by other editors.
Some potential advantages of using a wiki [48] are: (1) asynchronous collaborative involvement of all interest groups; (2) capturing thoughts and notes for dynamic projects where no proper media format exists; (3) easy exchange of ideas for small teams and projects; (4) provision of a creative environment to expand an organisational knowledge base; (5) creation of a 'level playing field' for all opinions; (6) higher efficiency than emails and discussion forums; (7) better understanding among all participants; (8) harnessing the power of diversity of contributions; (9) provision of a knowledge development and sharing forum; and (10) provision of innovative project reference repositories.
Challenges associated with the use of wikis include [48]: (1) the effort involved in editing and maintenance; (2) perceived lack of control, a formal hierarchy, and accountability; (3) legal liability, privacy, and security issues; (4) concerns related to content accuracy, comprehensiveness, balance, consistency, and reliability; (5) the cumulative and asynchronous rather than serial nature of wikis; and (6) the mixed degree of the content's quality and finality.
The scope of the wikis in the Web 2.0 collaboration solution for implementing an enterprise system relies on the peer review mechanism to ensure the highest level of accuracy and completeness.It is expected that subject matter experts will contribute and review the information related to the solution.

Blogs
A 'blog' is an online journal authored by an individual or a group.It contains dated entries in reverse chronological order, showing the most recent entry first [49].Blog entries can contain linked information.Blogging tools generally allow (1) the creation of commentaries on the other posts or entries; and (2) non-technical users to create and publish websites without using complex programming tools [50].
A blog can be particularly useful in a project environment as a tool to communicate the status of the project, and to provide critical project management information while allowing feedback from project team members.
Top management could demonstrate support by providing regular status updates and feedback as part of a change management process.The type and tone of comments can give managers a feel for the 'soft' issues of the project.

RSS feeds
RSS ('Really Simple Syndication') [51] is a web content syndication format that allows not just links to a web page but a way of actually subscribing to it [52].A subscriber will get a notification every time the website page changes.O'Reilly [52] calls it 'the incremental web' or the 'live web'.
Notifications can be viewed in an aggregator to provide users access to all changes in all websites subscribed to.This is particularly useful when it is important to track changes in, for example, the project management blog or the wiki with the latest product update information.

An open source perspective on change management
Neus and Scherf [53] provide an open source perspective on change management.The contrast between the 'Brooks' Law' approach (where a small team of 'experts' develops a software solution) and the 'Linus' Law' approach (where mass collaboration contributes to the development of a software solution) provides insights into the different approaches to change culture.
The traditional approach of enterprise system implementation projects is to gather a few subject matter experts, create an isolated team, develop a solution based on their understanding of the requirements, and introduce it to end users in its final state.The open source approach allows contributors from various areas in the organisation to participate in the definition of requirements, configuration, testing, documentation, and training for the solution.The visible components of the organisation -such as tools, processes, roles, and the organisational structure -are a small part of an organisation [53].The organisational 'culture', which includes behaviour, values, customs, heuristics, beliefs, stereotypes, and taboos, is generally invisible; but it contributes significantly to change management challenges, as it is seldom addressed in change management planning.This open source approach has the potential to assist with cultural change when deploying BPMS.

The open source approach to collaboration and communication
Similar to enterprise systems implementation projects, open source software development projects are coordination-intensive, and are often developed in geographically dispersed areas [38].
It should be noted that open source contributors are mostly freelance contributors to a project who do not face the same commercial pressures typically found in enterprise systems implementation projects.This is a key area where the open source development approach differs from the requirements of the implementation of a BPMS, which generally has tight project deadlines and is staffed by fulltime employees.The open source collaboration model does, however, provide evidence of successful, self-organising groups that use electronic media effectively to design, develop, and support complex software solutions.
There is an informal hierarchy in open source development that ensures that individuals earn the right to contribute to a project.The peer management processes are generally well-understood and well-supported.In enterprise system projects, because of their commercial nature, fixed implementation deadlines, and scarce resources, it is important to have a defined organisational approach.
Bergquist and Ljungberg [54] refer to the 'gift' relationships and behaviour that forms a cornerstone of the open source movement.This implies that an open source approach to enterprise systems implementation should foster open and giving cultures rather than an exchange where only a few members benefit.
The open source community is organised around a large group of producers and users.Tapscott and Williams [50] define these as 'prosumers': the producers of content are also the consumers.An important reason why developers contribute to the project is to ensure that the features and functions that they particularly require are added to the product [38].
The 'emperor's clothes' test used by Neus and Scherf [53] checks whether, in an organisation, a novice (end user or practitioner) can publicly call attention to the emperor's (the expert's) 'lack of clothes'-that is, raise a quality issue -without being blocked by any gatekeepers who manage the communication flow.In an open source organisation the novice would be able to publish any issue directly to the project website.
The downside -which needs to be managed -is that open source projects can suffer from negative influences such as 'elitism', where the elite are protected by 'flaming' contributions from authors outside of the elitist group [53].
Spontaneous work in specific areas of interest has a potentially significant impact on allowing individuals to innovate.
Concerning a Web 2.0 collaborative technology framework, the following lessons apply, based on open source approach to collaboration.(1) Peer management processes are applicable.There should be a defined hierarchy and role structure based on the open source software development model.( 2) The contributor will have the opportunity to ensure that his/her specific requirements are documented in the process requirements for the BPMS.(3) A solution should not suffer from 'elitism', where certain contributors are 'flamed' for organisational or political reasons.It will require top management support to ensure that everyone is treated fairly and that all contributions are evaluated based on the business value of the content.

Introduction
The aim of this section is to demonstrate how a Web 2.0-based model might be defined that can practically address the components of change management discussed previously.The conceptual model will be called 'Elixir' for the purposes of this paper.

Elixir business process management suite model overview
Orlikowski and Hofman [15] use the analogy of two open sea navigation approaches used in earlier centuries.The European navigator creates a detailed plan with a defined course that is charted, based on defined principles, and the voyage is based on strictly sticking to the plan.Deviations from the plan require re-planning and re-charting before the voyage can continue.Turkish navigators, in contrast, start with an objective rather than a plan.The Turk sets off toward the objective and responds to conditions as these occur, mostly in an adhoc fashion.
The Elixir conceptual model provides a toolset for the navigator travelling through the uncharted territory of business process management in large organisations.The BPMS project requires input and collaboration from all areas of business if it is to succeed in achieving the objectives of BPM and an organisational improvement methodology.
Elixir is based on the approach that having an objective is better than having a well-defined plan.Just as the open source model is based on a common objective [54] rather than a complex project plan, so Elixir tries to create a common objective for BPMS implementations.An agile approach is therefore taken, rather than a structured conventional approach.
The model is based on an extension of the Deloitte Consulting FastTrack 4SAP methodology [55].This entails the management of six project threads (i.e.project management, process architecture and engineering, technology architecture, process and systems integrity, change management, and documentation) across all project phases.(Theproject phases in this model are scoping and planning, process discovery, process and services design, configuration and integration, testing and delivery, and continuous optimisation.)The objective of this paper is not to examine or comment on the validity of the model, but rather to give an example of the externalisation of the model to support change management as a critical success factor.
The objective of the Web 2.0 collaboration platform is to provide an effective mechanism for the collaboration and communication required to support successful management of the change management thread across all project phases.The activities, deliverables, and outcomes of each thread in each project phase on the Elixir model can be changed to accommodate the specific project, the maturity of the business, and the culture of the organisation.The proposed Web 2.0 model can be used as a communication mechanism for the customisation of the methodology, and to ensure that all project participants have the latest and relevant structure.

Components of Elixir model
The collaboration component of Elixir is based on Microsoft SharePoint technology, and is essentially a set of web sites that support blogs, wikis, discussion forums, and shared content.The components of Figure 1 show a simple configuration for the proposed Web 2.0 solution, containing all the elements that will be required to manage change as a critical success factor during BPMS implementations.
The discussion of Web 2.0 focuses on the BPM 'team room' that supports virtual teams with customised configurations of the collaboration components of SharePoint.
The main BPM team room in the sample site shows a landing page that includes project announcements, discussions, process value maps, calendars, workflow tasks, and links to other web pages of the solution.The process value map is done so that the user can select the desired process area by selecting the hyperlink on the image.The business value map puts the processes in perspective, as a business user or process analyst can give a sense of where a specific process fits into the bigger picture.
The announcements and discussions provide continuous feedback to project team members on any specific information that may be relevant to the team at that point.Information can even be distributed to non-project members, sponsors, and end users.It makes the project transparent, gives a sense of the level of motivation and attitude of the team members, and highlights potential challenges or threats to the project.Those who are interested in these announcements and discussions can subscribe to RSS feeds that will notify them of any changes as soon as they are published.Project members thus do not have to wait for project status update meetings to be notified of project-specific issues.
The workflow tasks display outstanding action items and accessible tasks to people with the relevant access levels.This provides real-time notification of any new activities or outstanding tasks in the same collaborative Web 2.0 environment as the rest of the project information.
The procurement 'team room' focuses on the procurement aspects of the enterprise system implementation, with a separate environment for team members who are involved in that aspect of the project.Access can be limited, but it is proposed, in the spirit of open source, to allow all users access to all areas to gain trust and to improve the quality of the information that is published in the various areas.The procurement team room features its own discussion area, documents relevant to that section of the project, and specific tasks.
It also provides a link to a procurement knowledge base wiki -referred to in Elixir as a 'kWiki'.

Knowledge wikis in Elixir
The knowledge wikis or 'kWikis' allow users at various levels of the organisation to contribute to the collective knowledge of the specific domain.
The procurement kWiki is used in the initial visioning and targeting phase to define the high-level scope of the process requirements, and could be expanded in future project phases.The initial contributions are generally from subject matter experts assigned to the project team; but the objective is to allow business users who use the processes on a regular basis to review and update the kWiki information.These users tend to identify scenarios and use cases that the project team may have not considered, and also identify potential challenges or threats with a specific process approach.The process discovery phase typically describes the current ('As-Is') processes.Using a Wiki to establish the details of the current processes increases the likelihood that all the possible process scenarios and variables are documented.A wiki also allows end users to contribute during the process and services design phase, to ensure that the proposed new process will achieve the desired outcome.It allows end users to be part of the 'To-Be' specification of business processes.The procurement kWiki in the example links into a number of different wiki pages that are all relevant to procurement processes in the organisation.The kWiki describes the scope of the process, various use cases, specific constraints, roles, and users who use the process, and various other parameters that the subject matter experts may feel relevant.It develops more content as the project continues, with improved levels of granularity and refinement as other parties review and update information.
The wikis can be easily edited, but information from previous versions is kept to ensure that the content editor -typically the process owner -can roll back to previous versions if necessary.The name, time, and date stamp of the last contributor is shown; in line with the open source approach, this ensures transparency.
These knowledge wikis are a key to the requirements definition of the project, and provide a reference for testing, an instruction guide to future work, and a knowledge source for post-deployment phases and further process improvement projects.
It is proposed that a process owner is appointed for each process cycle, such as 'procure to pay', and that these process owners also serve as content editors and final adjudicators, as they are still primarily responsible for the output of the process.
Any interested user can subscribe to an RSS feed to be notified of any changes in the Wiki.

Blogs and RSS feeds in Elixir
Blogs can have various applications in the proposed Elixir model.Two primary ones are discussed.
A project manager blog can support communication from the project manager on a realtime basis.Team members can subscribe to the project manager blog through RSS to get immediate notification of project-related communications.Project risks and issues can be highlighted immediately, and respondents can provide comments on an ongoing basis.A journal is kept of all entries for the duration of the project.
It requires a mature team to use it in a constructive way, rather than for negative feedback, political agendas, or 'flaming' especially of junior team members.
A blog is also used to compile a daily task lists journal.
The journal list of completed tasks details specific approaches or methods used, and serves as an audit trail for later reference.It provides feedback to the project manager on the current status of specific activities, with the ability to post a comment and possibly request more detail on specific tasks that may require additional information.
Providing a list of tasks planned for the current day forces team members to make a commitment to the group that certain tasks will be completed.The peer review mechanism ensures that the developers maintain a high quality task blog, and that they identify and list impediments or threats very early on when potential challenges are encountered.Team members also ensure that their tasks are substantial, as their peers have full access to see what they are working on.
Fellow team members can provide useful contributions in the form of comments when they have completed similar tasks, have domain experience, or have possible solutions to impediments.
A further application is the creation of subject matter blogs where domain experts enter into a discussion before posting information to the relevant knowledge wiki.

Shared documents in Elixir
It is possible to create a single document repository for some projects, while other projects may require individual repositories based on functional area, process, or any other projectspecific segment.
The repository allows for versioning and extensive authoring rights.Users can be notified of changes to documents and document statuses through RSS feeds, and this knowledgesharing capability ensures that virtual teams are supported in the creation, storage, management, and use of project specific artefacts.

Team surveys
It is useful get an indication of employee morale and other organisational behaviour parameters.The model provides the ability to construct team member surveys that can measure project-specific questions during each phase of the project.

CONCLUSIONS AND RECOMMENDATIONS
Implementing enterprise systems in medium to large organisations is challenging and problematic.As newcomers to the enterprise system environment, BPMS risk suffering the same fate as other enterprise systems.Most critical success factors are not technical, but rather centre around the human aspects of the implementation.
Change management ranked second to top management commitment and support as a critical success factor for ERP implementation.
Collaboration and communication during change management are factors that can be supported through Web 2.0 technologies.An analogy between open source development projects and enterprise system implementation projects shows the similarity of the collaboration requirements; but it also highlights some of the organisational characteristics required for successful collaborative system design and development.

Figure 1 :
Figure 1: Configuration for Web 2.0 collaborative solution