While you are implementing the application, the business analysts can also resume working. Introducing a new application to the organization will most likely require a review of current practices to make any adaptations necessary to incorporate the application into the organization. In business analyst terms, this is called business process redesign/reengineering (BPR). Depending on the size of the new applications, or the number of business processes it affects, BPR can vary from little change to significant change.The reason for introducing a new application to a business it to improve their business and efficiency. Since the new application will incorporate part of the existing business processes, if not take over a number of them, it is sure to impact the current organization.
Change can be very threatening to some employees, so a business analyst should take this into consideration when introducing a new way of conducting business.The introduction of a new application, especially a big one, is a very delicate process. Do not call it redesigning or reengineering, since this is often interpreted as "we are doing things wrong, and some outsider is going to tell us how we should do our work." Refer to it instead as a "business process adaptation/evolve-ment," and get the employees directly involved. One of the reasons in getting stakeholders directly involved, besides the fact that they are good sources of information, is that by making them part of the "team," they will accept the solution more readily if it is seen as being partly their solution. It is inevitable that processes have to be adapted and the employees directly involved with the new application will have to do new things. However, by making them part of that process, by inviting them to help think of the best solution, it is unlikely they will not accept working with the new application. Here are some guidelines for this review process:
■ Take inventory of the current business processes that will be embedded in the new application, partially or totally. Make a detailed description of how these processes currently work and interact with other processes.
■ Take inventory of the processes that interact with the processes that are going to be (partially) embedded in the new application. Make a detailed description of how these processes interact with the processes that are going to be part of the new application.
■ Make an initial assessment on how both groups of processes are going to be changed.
■ Take inventory of the employees involved in these processes and the roles they currently play.
■ Talk to these employees and explain the situation. Encourage them to help you come up with solutions to embed the new application in the organization.You can use the same group technique discussed previously in the sidebar "Users Hold the Key to the Requirements."
■ Important goals are (1) the way the application is going to interact with current processes; (2) the roles involved with the new application; and (3) the new tasks the new application introduces.
■ Assess how these new roles and tasks should be divided among the employees. Make it known to them and ask for their cooperation.
■ Provide adequate training for using the new application.
Of course, it is more complex than this, but we are writing a developer's guide about BizTalk Server 2000, not a book on BPR.We want to make sure that you understand that this part of the development process is as important as the actual building of the application, if not more so. Again, you are working with people.The application you helped build can be perfect for its task, but if it is not used correctly, it will be rated a failure.The history of IT projects is riddled with failures, not necessarily because the applications themselves were poorly designed, but because employees were left out of the equation.
Was this article helpful?