|
|
|
Tying it all together
|
What is a business solution architecture?
Business Release Planning
- First Business Release
It is often impossible to effectively implement more than a few supporting
technologies at a time, due to the capacity any business has to manage change
at one time. However, it is true that implementing one product at a time provides
far fewer business benefits than a synergistic set. Cost benefits are greatly
increased when complementary technologies are implemented and integrated
within a short space of time. This is because of the synergy these technologies
provide in effectively supporting the workflow along major sections of some key
end-to-end business processes. A business release scope (BR#) may also be
selected to only support a sub-set of the business process work types until some
later BR# completes the full work-type scope.
When the most cost-effective suite of products to support the first Business
Release (BR1) is implemented, the relevant baseline definition for the BR1-BSA
is developed. It covers the scope, process architecture (IBPM), and system
architecture to be developed during the first business release.
- Subsequent Business Release Planning
Business release scope and phasing is developed based on the business
requirement dependencies, system capabilities, integration requirements, and
related data requirements. The relatively long time to appropriately configure,
populate data, and integrate a utility facilities database using GIS technology
clearly illustrates the required business release timing dependency. The scope,
dependency sequencing, and timing of the various business releases are
defined. The BSA includes sections that define the BR1, BR2, BR3, etc.,
business solution architecture baselines. These together with the vision solution
architecture form the phased implementation plan.
Business Release Development
- Detailed Functional & Integration Requirements
Using best practices experience, detailed end-to-end business processes are
then developed to support the various types of work. An example of this is the
objective to incorporate operational data maintenance into day-to-day operational
business processes without post-capturing.
The various product configuration (codes and preference settings) are agreed to
in principle and tested to ensure a workable business solution for the full range of
work-types to be supported. Essential work-around and customization needs are
motivated. High-level incremental business case impact analysis of
customization and add-on functionality needs are evaluated. This together with
the appropriate timing determines the prioritized list of customization and add-on
functionality that will form the scope of the various business release solutions.
The detailed integration requirements are then defined. Changes to the previous
baseline of the BSA need to be motivated as part of the requirement definition.
Operational test scripts and acceptance criteria are developed based on these
end-to-end business processes.
- Detailed Data Requirements
In parallel with this step, the data requirement specifications and acceptance
criteria need to be defined based on business concepts and terminology. The
data rework and clean-up activities need to be identified and planned for in the
program plan to ensure the appropriate business experts are available to perform
this work. These people need to be the people who in the future organization will
be responsible for managing the various core data sets. Data quality is critical for
end-user acceptance of the business solution and for commitment to achieving
the agreed business benefits. Inaccurate or incomplete data cause users to
blame the system; to not use it and revert back to their previous systems. This
will cause an ineffective solution implementation and will only be resolved when
the executives accountable for the data sets are made to sort out the problems.
These types of problems emphasize the importance of executive management
buy-in and commitment to the business solution and the appropriate allocation of
accountabilities for data, systems, and business processes defined in the BSA.
- Detailed Design Specifications
The detailed design phase follows with clear traceability to the business
requirements. Version changes required to the previous baseline of the BSA
System Architecture needs to be recommended for approval. It is during this
phase that the detailed configuration specification of the commercial products is
determined and tested for full consistency across the various business
processes.
Having defined the BSA and detailed business requirements enables the detailed
design specifications to be developed most effectively. It eliminates much of the
architecture changes and resulting rework associated with product or
department-focused solutions.
In parallel with the detailed design phase, the data population specifications need
to be finalized and executed. The data conversion, testing and loading
specifications need to be defined in detailed data modeling concepts and
technical terms.
Conclusion
A major business transformation program requires a number of specialist skills
and indepth experience of the business processes and available technologies.
The transformation planning needs to include an indepth understanding of the
peculiar issues associated with each of these technologies and their effective
integration. It is recommended that a third-party independent system integrator
be engaged to support the utility through such a major business transformation
program.
The development of a BSA document that provides the overall strategic direction
and roadmap for the approved business transformation program and various
business releases is essential.
|
|
|
|
