Page 138 -

Overview 117

Business Benefits and Ramifications

The primary benefit is the ability to see the activity that is required to operate the DG program. Of
course, the downside could also be that the business gets to see what is required to operate the DG
program! The bottom line is that you have moved from abstraction to reality.
Approach Considerations

The information principles (and specifically the implications) are used as a basis for initial identifi-
cation of policies. The team will merge these with a generic set of processes typical to a DG program.
The essential DG processes need to address a basic functional cycle of plan, design, manage, and
operate, while also covering processes to:
• Sustain key business measures or metrics models
• Support standards, controls, and policies
• Support master data and ERP projects
• Support regulatory drivers
• Manage enterprise data model standards and procedures
• Manage processes for reference and code data
• Plan and manage the DG program itself, including processes to administer policies and standards
Once the DG team has assembled a list of DG processes, they can work through a rationalization
process and make sure there are no policies in place that could conflict with the new DG processes.
Separately, the team can address regulatory items, such as security, privacy, and compliance.
Data controls are also important, especially in a financial services environment. Many of our clients
base their data governance on COBIT, a standard framework for data control and financial governance.
Don’t forget processes to support compliance, regulatory, security, and privacy areas. These will be
very visible DG functions. Most organizations have security and privacy areas in place, so coordi-
nation and leverage with existing policies in this area are important. If the policies already exist, make
sure they are adopted into DG.
Lastly, the team needs to strongly consider some process design, especially for key functions such
as issue resolution or maintaining and implementing new policies. Walking through these will give
a great indication of the amount of change the organization will undergo. This includes changes to the
development methods used by IT to implement systems. These are referred to as the system devel-
opment life cycle (SDLC) methods and can take a variety of forms (Agile, waterfall, iterative, etc.).
Regardless of form, the DG program will require changes to internal SDLCs.
Sample Output

Figure 10-10 shows an example of the standard list of DG functions we use. The entire list is in the
appendices, including the basic IM functions. Sorry to force you to the back of the book, but space is
limited for these larger lists.
Tips for Success

If you receive feedback upon review of your functional design that it is “too much,” remind the critics
that business functional areas have similar sets of activity.
A common mistake is to fail to keep the design of information management processes separate
from data governance processes. The next activity gets specific about information management
processes. The lack of separation is usually because the initial staffing of DG is drawn from