Upgrading from QPR ProcessDesigner to QPR EnterpriseArchitect - Why and when?

1 post 0 new
Log in or register to post comments.

Upgrading from QPR ProcessDesigner to QPR EnterpriseArchitect - Why and when?

Developing business operations requires competences, processes, methods, and naturally also tools like QPR ProcessDesigner. Acquiring and setting up these is an evolution process itself, taking time and money, and an understanding about which things come first. Many organizations choose to start from business process management and improvement, driven  by their strategic objectives, operational efficiency needs, or quality system requirements. The initial need is different in different organizations.

Once the initial need has been successfully satisfied, focus shifts to the next steps. Given an internal success story, the world of systematic operational development gradually opens up to the management. It is likely that over time someone develops the idea that their process management approach should be extended to consider the application landscape as well. After all, most of the business processes are critically dependent on the use of ICT systems, so how do we manage this critical dependency? This requires the mapping of applications to the processes and activities. This is a natural reason to upgrade to QPR EnterpriseArchitect, since there you can do this mapping, and also describe the dependencies and data flows between the applications themselves.

Another organization discovers that they have successfully defined processes, roles, and responsibilities for the purpose of their ISO9000 certification, but the handovers between people, or the interfaces between processes and activities are largely undefined or informal to the extent that it results in a lot of discrepancy and waste. Soon they discover the need to more formally define the information that the processes create and which flows between people and their various activities. In practice, many enterprises at this point launch a master data management program, as the first step. Again, this is a natural reason to upgrade to QPR EnterpriseArchitect, since there you can define the interfaces and information models, and also the application architecture that streamlines the process integration by automating the storage and transfer of this information.

It is also common to expand the scope of operational development in the context of large and complex structural changes, like mergers, acquisitions, divestments, and outcourcing. The challenge comes from the fact that they affect all dimensions of the enterprise architecture: business models, organization, processes, applications, and ICT infrastructure. QPR EnterpriseArchitect is an ideal tool for analysing the impact of structural changes in all dimensions, and for planning how to manage the dependencies for the success of the enterprise restructuring operation. However, the required rapid ramp-up of the enterprise architecture capability in this context requires substantial effort, which usually means extensive use of enterprise architecture consulting services.

Along with discovering the capability upgrade steps like the above, the organization needs to further mature its operational development by identifying the need for new competences. Mere process modeling is not enough, but information modeling and ICT architecture are also necessary competences. It may be necessary also to critically review the governance model, since for example enterprise level information architecture or deep structural changes require a centralized team, as opposed to process architecture, which often can be more distributed.