Barring other considerations, you should implement business systems according to their position in the business life cycle. That is, if any procedure in business system B requires information captured in business system A, then business system A should be implemented before business system B.
This ordering, sometimes called the natural implementation sequence, can be deduced from dependencies in the activity model and from the clustered Entity Type/Elementary Process Matrix.
For an example, see the following illustration.
Read interactions that lie outside clusters potentially represent the need of the activities in one cluster for information created by activities in another cluster. These "reads" represent a transition dependency.
For example, the process Set Prices reads the entity type vendor product, to check vendor product price, which is created by the Purchase process in the Purchasing cluster. If a Purchasing system is implemented before Pricing, this poses no problem.
Sometimes, deviation from this natural sequence becomes necessary. Many non-technical factors can render the natural sequence impractical, such as management and user pressures, the desire to implement higher benefit systems first, and a variety of resource constraints.
For example, Purchasing may be the highest business priority. However, the matrix in the illustration also shows that many of the processes grouped into the Purchasing cluster read product and product price. You should therefore discover whether the information available from current systems is sufficient for the purposes of Purchasing.
Any time there is a deviation from the natural sequence, there is a risk of introducing logical inconsistencies that, in turn, require additional resources to resolve. Consider this additional cost (the cost of implementing systems out of their natural order) whenever such a deviation is proposed and offer the business a choice of implementation strategy, costs, and risks.
|
Copyright © 2014 CA.
All rights reserved.
|
|