In this chapter, highlight some of the project planning aspects of getting to the Compiere system's go-live milestone and beyond. We will cover:
- The issues around the people involved in the project
- Overview of aspects regarding technical and functional environments
- The go-live milestone
- Identifying aspects regarding post-implementation, including support
- An overview of keeping Compiere up-to-date, and its migration process
A system could be defined as an abstract entity that maintains its existence through the mutual interaction of its components/actors. The success of these interactions is determined by an organizations' people. From the outset of a new implementation project, it is required of management to engage, manage, motivate, and evaluate the people involved in the project, throughout the duration of the project.
Implementing an ERP system requires significant change and buy-in throughout the business. People will learn new skills and work in a new or different way. This requires decision making, as well as a top-down approach within the company structures. In realising the changes required, it is thus important to note that the key people within the project be identified early, and that they be appropriately incentivized to stay on board for the duration of the project. These key staff members may include the original project initiators, key project members, and user staff members that know the aspects of the business very well. Also important will be the investment in such staff members from a training point of view. The key to success is to ensure that the new knowledge is contained within the project and within the organization for as long as possible.
On conclusion of the project, it is also important for these staff members to be available, because for a while they will be the key people that users and management refer to for the detailed knowledge and impact of business process and system requirements.
An integrated ERP environment may not have every person in the organization's buy-in, and users and management that do not buy in to the processes need to be identified and appropriately addressed as soon as possible. The best outcome is that these users are specifically re-trained in their area, or that their concerns are addressed through the correct channels. But even with all of the change management, communication, project meetings, and functional training, some users still either see a new system as a threat or simply just don't buy in to the new processes, because they may be adverse to change. These types of users create a negative atmosphere and may, in extreme circumstances, cause deliberate damage to the process. Sadly, these users often sabotage the project before they even have the necessary information and experience to make an informed decision.
It is critical for the communication level within the project to be appropriate for the different stages of the project. The key driver in change management process is communication. Communication has many forms, and includes staff conferences, posters-on-the-wall, meetings, email, web portals, events, forums, surveys, or any format currently used within the organization to communicate issues.
The project will start to fail when action items are not communicated and followed through within the timeframe required. Action items should be communicated after every meeting, and accountability assigned. The status of such items should be followed up consistently and reported with the aim of ensuring consistent transparency and corrective action prior to getting serious issues that could affect the project further down the line. The key to communication is that it instils confidence throughout the project and the organization. Key issues and decisions should be communicated by management and not by the project, as communication by management will reinforce the perception that business is taking ownership of the processes.
No project can be a success without key management buy-in at the appropriate decision-maker level, and at the level of detail required. Whether that is at CEO, CFO, or CIO level depends on the issue, but it is important that they be the drivers of the process.
Another foundation for the success of the project is documentation control. This is true for any size of project, and entails the following:
- Appropriate project templates and sign-off: Regardless of the project methodology, document templates formalize the process and commit all parties to the agreed process, and sign-off ensures appropriate accountability.
- Compiling and managing documentation for business process knowledge: A tremendous amount of knowledge builds up during an ERP implementation, and it is important to document this.
- Documentation of testing: Testing processes and results should be documented and agreed upon.
- Documentation of technical aspects: The IT infrastructure team should ensure that all technical aspects of the project are appropriately documented.
- End user training documentation: It is critical that this be relevant and up-to-date with the latest changes, and should be simple enough for new users to easily understand.
- Managing documentation repositories: There is no point in having documentation if it cannot easily be accessed by the correct user. Whether this is done on an electronic Wiki basis, through the use of shared directory repositories, or through traditional lever arch files, it should be natural and should fit the business.