Business Process Improvement

Process re-design patterns

A process re-design is a general approach to re-designing processes for their improvement

Harmon describes four basic re-design patterns

(a) Re-engineering(b) Simplification(c) Value-added analysis(d) Gaps and disconnects

Re-engineering

Fundamental re-thinking and re-design Measures of performance – cost, quality,

service and speed Large scale improvement, hardly re-design Highly disruptive – risk of failure high

Simplification

Businesses develop elements of duplication or redundancy

A moderate approach to cut overlaps in functions

Identification and modeling Duplicate activities removed Judgment and flexibility Simple processes to replace two existing

ones

Value added analysis

Eliminate processes that do not add value See processes from customer’s perspective Value adding activities and value enabling activities It can be done by minimizing control and inspection

by empowering Improvement in workplace layout Improvement in workflow systems Activities that result from delay require careful

investigation

Gaps and disconnects

Processes problems could be due to failures of communication between business departments and functions

Gaps and disconnects are produced in processes and management

When information pass from one department to another, at those points gaps can be identified

Can exist: organization as whole, the process or job/performance level

Feasibility Technical: assessment of technological impact. Also

areas of expertise such as marketing, financial strategy, HRM

Social: management implication to most projects, in the areas of forming, leading and motivating the project teams. Potential problems: redundancies, training requirements, new work patterns

Environment: concerns about the impact of new process on the environment

Financial: cost benefit analysis. Whether the exercise is worth undertaking. Whether it would yield the desired results.

Standard Software Packages

ERP – general characteristics Robust systems, business process automation Based on standard modules Competitive edge claim: questionable An effective way of doing things One size fits all solution Beginning with a solution not analyzing the problem ERP forces the organization to adjust itself to the

software requirements

Issues with ERP

Customization could be a mistake the cost advantage is lost Introduction is delayed Reliability is reduced Problems with upgrades Acquiring source code In-house modification Internal developer not familiar with ERP structure Upgrades may pose problems Question mark on developmental potential of ERP

Advantages of software package over in-house dev

Cost savings Time savings Quality Documentation and training Maintenance support

Disadvantages

Property rights Financial stability of supplier not guaranteed Inadequate performance: over performance,

under performance Lack of functionality Changing requirements

Establishing Software Requirements Interviews: face to face interaction, business

background, technical context, issues & constraints, current work flow procedures and data, requirements for the new system

Questionnaires: precise answers to questions, flexible timings, bereft of body language

Written questions: for specific and detailed answers Observation: a better way of understanding

requirements Protocol analysis: understanding from client’s hands

on experience. What happens when one does something

Document analysis: sifting through paper work and records

Workshops: meeting people in groups, having presentations to ascertain their needs and requirements

Prototyping: a mock model for gathering feedback and input from the user

Existing Systems: analysis, identification, re-design, proto-typing, implementation

Assessing Software Packages Functional requirements: things that software must

do. High weight-age Non-functional requirements: not directly related to

the processes, legal requirements etc Technical requirements: hard ware, operating

system, languages Design requirements: architecture, internal design

(modules), configuration Supplier stability requirements: future support by

supplier, financial position, track record, size and location, reputation, accreditation, quality assurance, dispute resolution

Assessing Software Packages

Supplier citizenship requirements: CSR, diversity, health n safety, trade unions, charitable donations, sustainability and environment

Initial implementation requirements: installation is carried out successfully, data transfer, manual input, software installation, introduction of new system, pilot operation, restricted data running, user training

Operability requirements: documentation, continuing support, upgrade policy, legal protection

Cost & Time constraints: important

Selecting software packages Obtaining tenders: identifying suppliers, ITT,

advertise, other means First pass selection: short listing on the basis of info

provided: functional and non-functional requirements, technical and design requirements, supplier and implementation requirements, time and cost

Second pass selection: short listed may be examined further, test runs, reference sites, financial investigations

Implementation: testing, training, data transfers Long-term relationship: product augmentation,

conflict avoidance, back up plans, escrow agreement