MANAGING ERP SECURITY

Types of security Issues

Network security System Access Security Role and authorisation Data Security

System access security

Activity based authorization Role-based authorization

Activity based authorization Identify the activities that a particular process may involve Prepare a set of transaction codes for each identified activity Prepare and authorization role for each set of transactions Assign the user specific authorization role Role based authorization Identify the transaction codes that each role in the organization requires Prepare an authorization role for the list of transactions identified Assign the user the specific authorization role Normally types of authorizations include create, change, delete and view

Data security and technology for managing data security

During ERP implementation process there will be a set of privileged users who will have access to companys sensitive / private data. An NDA (Non-disclosure agreement) is signed but this cannot ensure 100% security. Risk increases with offshore partners. Data Masking Shuffling / Reorder Random value Hashing ( eg. 645-348-1233 becomes 645-#48-####) Date-aging (eg 12 Jan 1978 .. Go back 2000 days 16 Mar 1972) Value changes in increments or decrements/numeric alternation Custom Substitution with random value

Data Migration

Challenges in migration of data From which source systems data will come ? How much data needs to be migrated How to clean the data Who will verify and ensure that clean data is loaded into the system Which electronic migration method or which ETL (Extraction, transformation and loading) tool is to be used Which data can be transferred earlier and which needs to be transferred just before going live ?

Understanding data.
Classification into master files and transaction files. Examples
Master files Chart of accounts Cost centres Profit centres Asset master Material master Price master Vendor master Customer master Employee master Machines / equipment masters Transactions files Order files Stock balances Material in transit Indents RFQ Sales orders Contracts Billing data Voucher data

Process to migrate data Manual data migration Electronic data migration Steps involved are
1. 2. 3. 4. 5. 6. 7. Analysis Design Cleansing Extraction Transform Load Verification

Process for data cleansing Identify critical data elements Refer to data standards for critical elements Define data validation rules by process owners Identify data issues from process owners Data quality assessment Take corrective action Improved data quality

Problems with data Same person spelt differently Multiple ways to denote company names (ABC systems, ABC pvt ltd, ABCPL) Same city with different names (BombayMumbai, Kochi Cochin) Different codes for the same customer Required and mandatory fields blank Extensive use of dummy values

Data cleansing techniques Standardising Matching Consolidating Correcting Enriching Parsing Conditioning Scoring

ETL tools help automating these techniques

(eg. Information Server (IBM), Oracle warehouse builder, SQL server integration services (Microsoft)

Cutover Planning and Go Live preparation

Cutover The final stage of ERP realization before the company moves on to the new system Phased cutover Complete cutover Cutover has to be planned to have minimum business disruption. Functions like customer invoicing, production schedule etc. should never stop as they may result in revenue losses. There should be a cut off date for each process in the old system.

Go live preparation
The day the company moves from the old legacy system to the new ERP application is called Go-Live date. All critical activities should be completed before this date. All configurations All developments All testing (Unit testing, Integration testing, user acceptance testing) Training for the core team, power users and end users Data migration completed All authorizations are created and authorization testing completed.

Go live Check list

External certifications Infrastructure User workstations Printers Security Cutover plan Quality assurance End user training Support Communication / Change management

Legends used for marking Green Ready Yellow Production ready with minor refinement Red Not ready to go-live

Go live Audit

Completeness of integration testing End user training End user acceptance testing and signoff Data migration Support help desk Period end closing procedure Critical open items

Training

Objectives of training

Prepare the users to use the ERP system in the most effective manner Prepare core users to train the end-users Make end-users comfortable with the system Prepare training material to be used as a readyreckoner

Training Strategy Who needs what kind of training Whether some part of the training will be outsourced Which training method to utilise Training environment Training locations Training duration planning Training content planning

Training environment

Moving from awareness to ability to perform

1. Show / tell 2. Practise
Awareness

3. Assess
4. Reinforce
Ability to perform

Training Environment

Identify training data required Create this data in the system Build the scenarios Test the scenarios Create User IDs for people who will use this training (login and password) Pilot for few users first

Train the trainer - advantages

Cost effective Forces the core team to understand the system better More acceptable to end-users than external people Easier to handle change management

Train the trainer

Teach how people learn The importance of using questions Training techniques and instructor behaviour Training preparation checklist Handling nervousness Presentation skills Handling difficult people Assessment techniques Reviewing training sessions Dry-run sessions

Train Delivery

Face to face learning

Instructor led Workshop Seminar

Self-paced
E-learning Weblecture Self-study Quick-reference guide System Simulations

Training content development

Training needs justification High-level design Build Pilot

Training evaluation

Questionnaire Training methods Content Trainer Formal and informal feedback

Training roles Training manager / Lead

Manage team / budget / schedule / content development coordination and evaluation

Training delivery co-ordinator

Train-the trainer / effectiveness review / method development / session co-ordination

Training content developer

Developing training materials / slides / screen capture demos / trainers guide / scenarios / dummy data

Change management

Why change management

Whether my job will remain What will be my new role Will I be able to take on the new role / will there be increase in work load Will I be comfortable with the ERP or what will happen to me Will the new role help in my career ERP is for tech savvy youngsters. I am too old for all these technologies

Strategy to handle change for the project team

First level Handle fear and uncertainity Communication Training Handhold by own team member Round the clock support Leadership support Second level Getting motivated and committed Understanding people and motivation Self motivation Desirable motivation Return based motivation

Involvement

Involve people in each critical stage Design incentive schemes and performance measures Design new and more interesting roles
Changes in organizational design New roles and responsibilites New reporting structure New job descriptions

Change team and change management roles

Core Change team Extended change team

Change management activities during lifecycle of a project

During project preparation During business blueprinting / designing ERP During realisation / building ERP systems During Go-live and project closing

At each stage Identify point person to manage project communication Methods and ways of communication Developing communication content Identify frequency of communication Develop change management training strategy Conduct training Evaluate training effectiveness

Change management Six Key Process of ASAP Assessment (Risk assessment)

Uncovering and prioritizing risks

Communications
Designing and delivering key messages

CORE

Sponsorship
Gaining and demonstrating leadership support

Skills development
Organizational change management training

Knowledge transfer
Capturing and sharing lessons learned

Organisation optimisation
Aligning jobs and processes with new business environment

SUPPORT ING

Success / Failure Of ERP Implementation

Reasons for failure of an ERP implmentation

Poor ERP package selection Inadequate requirement definition and unrealistic expectations and scope Investment without ROI justification Not able to support changing business needs
Lines between industries are blurring Lines between countries are blurring Industry itself is evolving

Top Management support lacking ERP Core team do not have the right resource User acceptance issues Employees resistance Training Issues Poor communication Project viewed as an IT project Customising the software too much Too tight project schedule miscalculation of time and effort High turnover rate of project team members

Failure avoidance
Define measures of success Managing project scope Requirements priortisation Pilots Good relationship with ERP vendor and consulting partner Good project management Having clean data in the system Quick decisions Test the solution thoroughly Sufficient budget Efficient risk management Process owner involvement

Application support

Support cycle

Phase 1 - Support planning Phase 2 - Transition Phase 3 - Hypercare Phase 4 - Steady state Phase 5 - Upgrade

Transition
Transition refers to a set of activities relating to the transfer of responsibility for work from one organization / a set of people to another organization or a new set of people Activities in a transition cycle Human resource transition Knowledge transition Project documentation transition Issue transition

Transition
Human resource transition
Location transition / transfers Role transition/new roles New team

Project documentation transition

Blueprints Business login / design doc. Development specs Configuration docs Test scripts

Knowledge transition
Clients business process knowledge Application specific knowledge Logics for configuration, developments, etc

Issue transition
Issue database Issue closing responsibility and closing dates

Steady state support - I

Regular system admin and technical management Daily database administration System performance monitoring Managing job schedules Managing technical infrastructure infrastructure

Change management Develop and implement change control procedure Change request management Applying regular patches, notes etc Managing regular tests (on changes) Transporting changes from development to production

Steady state support - II

Organizational change management Ongoing organisational change management Develop new ways of working End user application support Provide ongoing support to end users Root cause analysis of the problem Evaluation of support effectiveness Knowledge management Deliver continuous end user training Evaluate learning effectiveness Document lessons learned and best practices Solution database

Steady state support - III

Continuous improvement and ongoing KPI management Plan for continuous improvement Value realisation Measuring business benefits

Change management process roles

Business user / Request for change Service desk employee Change manager Change advisory board Developer Tester IT Operator

Change management cycle

User requests for a change Impact of the same analysed Change is made in the development environment and transferred to the quality environment Tested and transported to the production environment All documents updated

Upgrade advantages
Application vendors stop supporting the application New functionalities New version meets newer compliance requirements Upgraded version is on better platform and compatible with new offering from the vendor

Upgrade disadvantages / costs and risks

Cost of upgrade Business disruption Problems with new release Temporary decline in user productivity Upgradation may become must for multiple applications together

Type of upgrades
Technical upgrades
Fast and cheap Change management is minimal as there is no new process of business Reduces maintenance cost No business benefit to the company Mostly driven by the vendors roadmap no support if not upgraded

Functional upgrades
Business benefits Takes longer time and costs Change management necessary

Different levels of support

Level 1 support (1st level help desk ) Level 2 support ( in depth analysis and solution ) Level 3 support ( Expert advice and vendor contact )

1st, 2nd and 3rd levels of support

End user problem occurs
Face to face Telephone

Key user Solves handling problems Answers how to - questions

Telephone Email Support line feedback

User Help desk (1st level) Logging problems Search for known solutions Categorization of problems to proper support consultant

Vendor Support (3rd level) Solve bugs in application Expert consulting Solve issues that can not be solved by 1st and 2nd

Technical apps support (2nd level) Solving of technical issues Implementation of SAP net notes Runs background jobs Do system monitoring Maintenance of solution database

Functional apps support (2nd level) Solves functional issues Helps in functional testing Do configuration for functional change requirements Maintenance of solution database

Service contract and Service Level Agreement (SLA)

A service contract is a long term agreement with business partners that specifies the services offered for that period. Service level agreements (SLAs) are a subset of of contracts where customer is assured the performance of certain services with a predefined period of time. They normally contain factors like Response time Service window or availability time Downtime Availability Solution time

Service contract and Service Level Agreement (SLA)

A service contract is a long term agreement with business partners that specifies the services offered for that period. Service level agreements (SLAs) are a subset of of contracts where customer is assured the performance of certain services with a predefined period of time. They normally contain factors like Response time Service window or availability time Downtime Availability Solution time Generally SLAs are designed based on the severity level of the issue. Issues having the highest severity are defined as priority 1 (P1).

A sample Service Level Agreement (SLA)

Priority Level Definition Reaction time Standard Resolution Time Service Level Yearly Target

P1

Critical system processing has stopped. No workaround no bypass or alternative available

People can use a workaround Issue has no significant impact

1 hour

8 hours

97%

P2 P3

2 hours 4 hours

24 hours 3 working days 1 month

97% 95%

P4

Issue when deferred maintenance is acceptable

8 hours

95%

A sample Service Level Agreement (SLA)

Priority level P1 During desk support hours Initial update 2 hours after open time update every two hours after
Initial update 2 hours after open time update every 6 hours after Initial update 1 working day after open time update every 2 days after Initial update 2 working days after open time update weekly after

P2

P3

P4

Service Level Reporting (SLR)

SLRs are prepared on a monthly basis to see the SLA adherence Contains factors like Call resolution percentage of calls resolved by due date Call activity calls received, resolved and outstanding Incident statistics General support issues, escalation items and conflict incidents