0% found this document useful (0 votes)
58 views54 pages

How To Implement Ecm

Uploaded by

Dan Kelly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
58 views54 pages

How To Implement Ecm

Uploaded by

Dan Kelly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 54

How to implement ECM?

Global best practices for implementing ECM


using the open methodology MIKE2
Implementation

Which 3 of these typical problems have affected your organization’s


document or records management implementation?

Source:
AIIM ECM Survey
February, 2009
All respondents (284)

2
The MIKE2 Methodology

 "MIKE2 (Method for an Integrated Knowledge


Environment) is an Open Source methodology for
Enterprise Information Management"
 Source: mike2.openmethodology.org
 Developed by BearingPoint, released as Open Source under Creative
Commons

 Meant to be repeatable and deliver working systems


quickly, following trends in manufacturing and
commercial software development
 Continuous improvement (Lean)
 Repeating implementation cycles (Agile)

© AIIM | All rights reserved 3


MIKE2 Phases (description)

 Phase 1 - Business assessment


 Phase 2 - Technology assessment
 Phase 3 - Information management roadmap
 Phase 4 - Design increment
 Phase 5 - Incremental development, testing, deployment
and improvement

© AIIM | All rights reserved 4


MIKE2 Phase 1

Source: http://mike2.openmethodology.org
© AIIM | All rights reserved 5
Conduct initial direction setting with sponsor

 Sponsor needs to provide  Scope can be defined


insights across a number of
dimensions
 Difficult or impossible to
 Geographic
do everything at once
 Organisational
 Scale of change
 Legacy content
 Nature of the impact to the
organisation  Information types
 Cost  Information classes
 Timescales

 Prioritisation is key

© AIIM | All rights reserved 6


Programme charter: Overall approach

 Should be developed in 3  Environment: Develop


stages high-level descriptions of
 Current-state  Organisational behaviours
 The environment  ECM support organisation
 The principles & the future-state structure
 ECM processes & instruments
 Future-state
 Produce initial model
 Identify and consult stakeholders
across the organisation
 Review and revise

© AIIM | All rights reserved 7


Defining organisational behaviours

Guidance & Protocols Organisational behaviours


infrastructure FOR
What we use the

ECM Principles ECM 'Best Practices'


Examples:
• Duty to Share Examples:
• Information as a Corporate Drive • Team-working across Functions
Resource • Re-using, not re-inventing
• Collaborative Working • Proactive sharing of knowledge
The WAY we use
the infrastructure

ECM Rules ECM Procedures


Examples: Examples:
• Information must be stored in the • Procedure for requesting a new
appropriate location
• Information with corporate value
Drive •
Team Site
Procedure for declaring a record
is stored to the ECM Repository to the ECM Repository

© AIIM | All 8
rights reserved
Organisational QuickScan for information
development

 Analyses current-state of  Assessments


organisation across  Application portfolio and
multiple facets to identify functionality
the baseline for the  Information flow
organisation  Information delivery
 Aids in planning what it will take  Information maturity and
to get to the future-state vision infrastructure maturity
 Economic value of information
 Information processes
 People skills and organisational
structure

© AIIM | All rights reserved 9


Strategic business requirements

 Establishes the overall set of strategic business


requirements (business case) that translate into high
level information requirements
 Forms the basis for scoping the programme
 Strategic business vision
 Strategic critical success factors (CSFs)
 Strategic key performance indicators (KPIs)
 Strategic success measures
 Strategic change drivers

© AIIM | All rights reserved 10


Strategic business vision

 Defines what organisation wishes to achieve in the Future-


State
 Done by interviewing executives via scripts to capture
 Business objectives
 Competitive forces of concern
 Differentiation and positioning statements
 Major customers, buying habits and cycles
 Major suppliers and incentives
 Major competitors, substitutes and discriminators
 Industry and historical supply chains
 Success factors

© AIIM | All rights reserved 11


Business blueprint

 Key deliverable of MIKE2


 Final strategic analysis and synthesis of business
assessment work
 Completes and formalises the business vision

 Completion of business blueprint results in


 Prioritised requirements
 Programme plan
 Business case
 Programme blueprint

© AIIM | All rights reserved 12


Eat the elephant one bite at a time

 Go for specific projects,


one at a time
 Each project addresses
portion of ECM producing
business value
 Start with something nutritious,
not small and convenient

 Produce business case for


each of these projects
separately

© AIIM | All rights reserved 13


Prioritise requirements

 Refines the strategic information requirements


 Determines the sequence of projects
 Strategic vs. tactical
 Within scope and outside of scope

 Ranking done via group workshops with executives who


provided initial feedback
 With guidance of sponsor and stakeholders as appropriate
 Focus is on business requirements, not technology requirements

 Results in a list of work opportunities for the project

© AIIM | All rights reserved 14


Linking tactics to strategy

Drives
Contributes to (Balanced scorecard)

Management /
Strategic executive board
(C-level)

Operational
(Consequential impact) Business area managers

Users / other
Tactical
stakeholders

© AIIM | All rights reserved 15


Business blueprint components

 Arranged in key sections


 Executive summary
 High-level programme plan
 Business case
 Strategic case
 Economic case
 Funding case
 Commercial case
 Project management case
 Future-state conceptual architecture
 Appendix

© AIIM | All rights reserved 16


MIKE2 Phase 2

Source: http://mike2.openmethodology.org
© AIIM | All rights reserved 17
Technology assessment

 Concentrates on the technical aspects of your strategy


 Technology blueprint
 Strategically ties the business requirements developed in Phase 1 to a
logical and physical information architecture

 Completes the “strategic programme blueprint”


 Defines the overall programme delivery plan that provides the starting point
for the continuous implementation phase
 Refines the business requirements through ECM
 Defines the technology architecture
 Puts standards and technical infrastructure in place to support the software
development process

© AIIM | All rights reserved 18


Business drives technology

 Phase 1 and 2 parallelism


 Phase 1 deliverables must be completed before phase 2
can be completed
 Specifically, phase 2 requires the following from phase 1 before a full
infrastructure can be prescribed:
 Business vision
 High-level business case
 High-level information processes
 Scope of key systems

© AIIM | All rights reserved 19


How to produce requirements: Overview

 5 main stages
 1. Plan
 2. Gather
 3. Analyse
 4. Document
 5. Agree

 Some stages are iterative


and parts of entire process
can be iterative

© AIIM | All rights reserved 20


Conduct gap analysis of current-state and
future-state

 Identify key gaps between current-state architecture and


future-state
 Where will new capabilities be needed?
 What are those requirements?

 Becomes basis for RFP and vendor selection

© AIIM | All rights reserved 21


MIKE2 Governance model

Improved Governance and Operating Model

Source: http://mike2.openmethodology.org
© AIIM | All rights reserved 22
Why information governance?

 Accountability for organisation’s information assets


 Good governance
 Ensures compliance with regulations and legislation
 Enables productivity improvements
 Enables organisation to respond to change and new opportunities
 Helps information exchange with customers, partners and providers

 Sustains good information management practices

© AIIM | All rights reserved 23


An information governance framework (IGF)

 A sound IGF includes

© AIIM | All rights reserved 24


The role of ECM in information governance

 ECM environment is
 Key tool for Information Governance
 Repository for corporate memory

 ECM systems depend on creation and maintenance of


‘Content Management Instruments’, including:
 Reference data (taxonomy, thesaurus, etc.)
 Metadata standard for information, including documents, records, and
websites etc.
 Security and access classification scheme
 Disposition schedules

© AIIM | All rights reserved 25


Continuous improvement

Compliance Framework

Detect Respond
• Audit • Investigation
• Ombudsperson • Communication
• Monitoring • Improvements
• Employee discipline
Prevent
• Risk assessments
• Training
• Policies & procedures
• Executive
commitment
© AIIM | All rights reserved 26
MIKE2 Phase 3 Roadmap

• Roadmap

© AIIM | All rights reserved 27


Project roadmap overview

 Project roadmap is the guide for the entire project


 In each iteration of phase 3-5 however, it is the restricted guide for the
requirements and level of detail involved in a SINGLE iteration

 Tasks
 Define overall release functionality
 Identify and prioritise project risks
 Identify infrastructure dependencies
 Identify design dependencies
 Define acceptance procedures
 Define detailed project plan

© AIIM | All rights reserved 28


Identify and prioritise project risks

With each iteration, re-examine risks for iteration and project as a whole

Risk Likelihood Severity Mitigation


There is a risk to Medium Severe Have two key developers undergo
schedule and training.
quality as Have a third party specialising in this
developers are technology review high level designs
unfamiliar with before coding starts.
proposed Prototype first two function points
technology for the before the remainder of the code is
project developed.

© AIIM | All rights reserved 29


MIKE2 Phase 3 Foundation activities

 Software development readiness


 Enterprise information
architecture
 Taxonomy design
 Metadata development
 Solution architecture
definition/revision
 Prototype the solution
architecture

© AIIM | All rights reserved 30


Foundation activities (1)

 Focused on ensuring that the environment is ready and


that basic solution decisions have been made
 Important to establish at the beginning of each design,
develop, deploy increment
 Primarily focused on understanding information issues,
resolving these problems and defining target content
models
 If not conducted first, other subsequent implementation
work is likely to fail

Source: http://mike2.openmethodology.org
© AIIM | All rights reserved 31
Foundation activities (2)

 Technical and design foundations


 Iterative
 Risk assessment and management

© AIIM | All rights reserved 32


Taxonomic needs assessment

Cynefin framework

Source: Dave Snowden


© AIIM | All rights reserved 33
Developing a taxonomy

© AIIM | All rights reserved 34


MIKE2 Phase 4

Source: http://mike2.openmethodology.org
© AIIM | All rights reserved 35
Identify training and administration guide
requirements

 Used to estimate training needs


 Varies depending on complexity of the system, amount of change to the
organisation required and ability of users to absorb the material

 Questions answered
 What is the nature of the audience and the contexts they will be using the
ECM environment?
 Who will need the documentation, at what level, when and why?

 Typical targets for training


 Departmental users
 System operators
 Management

© AIIM | All rights reserved 36


Develop outlines for operational manuals

 There will be multiple operational manuals, targeted at the


specific audiences identified
 Typical examples
 User procedures manual – for specific business functions
 Operations procedures manual – for technical operations
 Desk procedures – how to do specific business jobs using the system

 Tasks
1.Examine existing operational manuals for corporate standards
2.Determine satisfaction with existing manuals
3.Based on identified requirements, build outline, vet with audience

© AIIM | All rights reserved 37


Design backup and recovery procedures

 If your solution is based on a single provider, single


repository - in a word, simple - fairly straightforward
 Distributed, federated, integrated solutions exponentially more complex
 Dirty secret of the ECM industry that backup and recovery is
exceedingly difficult
 Multiple repositories, integration paths, databases, indices, linkages
between documents and repositories

 Best approach
 Closely work with solution provider and/or integrators to design and
verify backup and recovery will actually work

© AIIM | All rights reserved 38


Business value of prototyping

uncertainty

uncertainty decreases over time

time
business value
Cumulative

Source (top): Barry Boehm


Source (bottom): Jeff Patton, www.agileproductdesign.com
© AIIM | All 39
rights reserved
All users have raised expectations

Source: NetFlix Source: Apple iTunes Music Store

© AIIM | All 40
rights reserved
MIKE2 Phase 5

 Develop
 Testing
 Training

 Deploy
 Operate
 Ongoing improvement

 Closeout

© AIIM | All rights reserved 41


Develop user support documentation

 Created to provide step-by-step documentation, with


appropriate screenshots, to illustrate an entire process
or task
 Supplements any automated processes implemented within the system

 Keep in mind how documentation is intended to be used


in YOUR environment
 Stand-alone reference manual
 Basis for live or on-demand training
 Develop at level of detail necessary for final use

© AIIM | All rights reserved 42


Develop operations support guides
 Introduction  Job scheduling
 Document distribution list  Monitoring & logging
 Document change process  Load balancing
 Application overview  Problem management
 Production environment  Change management
 Production architecture overview  Vendor management
 Production environment components  Backup/restore procedures for application
components
 Application servers
 System maintenance
 Web servers, etc.
 Print services
 Security  Failure
 Server security configurations
 Appendix A - User account setup process &
 Security log reviews access rights
 Guidelines for access  Appendix B - Service level agreements
 Account administration  Appendix C - Contact matrix
 Data centre procedures  Appendix D - Software versions list
 Startup/shutdown
Source:
http://mike2.openmethodology.org/wiki/Operations_Procedure_Outline_Deliverable_Template
© AIIM | All rights reserved 43
Technology backplane development

 Making this available as soon as possible is critical for the


development of ECM system
 Provides “developer ready” environment to build and test system based on
work done in foundation activities and design
 Acquisition and training of developers was covered in phase 4

 Tasks
 Implement target repository
 Develop content interface components
 Develop process/automation components
 Develop metadata management integration
 Develop infrastructure management processes

© AIIM | All rights reserved 44


User testing

 Pilots and model offices are popular approaches


 Refine design and implementation of new ecm-enabled environment by
directly involving users

 Pilot approach
 Trial of ‘draft’ proposed environment
 Uses a small subset of users
 Usually in their normal working environment

 Model office approach


 More of a ‘laboratory’ environment - somewhat rare
 Typically used to ‘get it right’, before moving to a pilot

© AIIM | All rights reserved 45


Model offices & pilot: Benefits

 Technical evaluation  Finalise environment


1. Functional testing  Ensure all aspects of
2. System integration testing environment are defined
(SIT)  Establish and ‘freeze’ a
3. End-to-end testing (E2E) configuration for roll-out
4. Stress and volume testing  Training development
(SVT)
 Develop and assess training
 Functionality evaluation materials and methods
 Does it do all that is specified  Train the trainers, help desk staff,
and required? floor-walkers
etc.

© AIIM | All rights reserved 46


Production deployment

 Post-pilot and/or model office work, the environment


finally reaches a deployment-ready state
 Final steps for deployment involved finalising how the
solution will be deployed technically for production use
 Tasks
1. Define distribution and installation method
2. Deploy baseline production environment
3. Deploy software to production

© AIIM | All rights reserved 47


Deploy software to production

 Solution is ready to be released into production, with


final evaluation and launch of the solution to the target
communities
 Production and operation procedures should be up and
running alongside the infrastructure itself

© AIIM | All rights reserved 48


Evaluation and launch

 Post technical deployment is the final evaluation,


scheduled launch and post-launch verification and
support
 Transfers operations and support from the
development/project team to operations personnel for
solution moving forward
 Contingency plans for any issues in final testing and
launch should be in place and ready to activate, should
any severe issues be identified
 Validates that system is truly ready for rollout

© AIIM | All rights reserved 49


Training feedback loop

 Collect feedback
 At the time
 And later

 Review, learn and improve

© AIIM | All rights reserved 50


Importance of change readiness assessment

 Organisational change will always appear threatening


 People think of job security
 Some enterprises more freely disseminate information regarding change
and strategy than others

 You need to assess your enterprise’s readiness to change


 Readiness of management and the workers affected by the change
 How technology is used (or not) within the organisation

 QuickScans and early assessments of Phase 1 provide


diagnostic tools, while this module is focused on
enabling necessary change

© AIIM | All rights reserved 51


Best practices for implementing change

 Change needs to be managed, but there are many


different methods for this
 However, these methods share common themes

 Most important theme: change occurs in the context of


the enterprise’s natural and recognised capabilities
 All successful models
 Address all elements of change
 Provide a process for introducing change
 Address critical success factors

© AIIM | All rights reserved 52


Creating user “wins”

 Early wins create a “Yes” environment


 Wins should be promoted widely

 Leverage existing and new “super users”


 Wins should be clear cut
 Not open to interpretation

 Wins should bring benefits to all


 Wins should appear to come easily
 Even a big bang approach can be delivered
via a series of smaller wins…

© AIIM | All rights reserved 53


AIIM ECM Specialist and Master Program
- learn how to impl. ECM

www.aiim.org/training
© AIIM | All rights reserved 54

You might also like