Custom and Standard Software

1
Custom and Standard Software
2

• Custom Software
• Individually developed applications for a
  specific companies purpose they perform specific
  tasks for the company.
• Historically, built used maintained in-house
• Increasingly outsourced
• Development risks costs covered by one
  organisation
• Software matched organisational needs
• Transaction processing easily supported
• Integrated systems difficult to develop

3
Custom Software Architecture in practice
4
The Desired Architecture.
5

• Standard Software
• Software designed for anonymous market
• Packages meet common business needs.
• Transaction systems are similar across
  businesses, traditionally focus on isolated
  business function(s).
• Developed by third parties.
• Packaged applications may be based on best
  practice.
• Includes other goods services
• Installation support Documentation
• Maintenance Training
• Characterised by
• Deliver known functions or solution
• General useability (across platforms
  organisations)
• Clear definition reduced system adaptation
  required
• Fixed price can be determined.

6

• Advantages of Standard Software
• Lower cost for functionality
• Migration is more predictable
• Reduced maintenance costs
• In-house IS focuses on other non-standard
  problems
• Time saving because solution is ready
• Data and Function are integrated
• Consistent user interface
• Modern software technology used
• (in house can not keep up)
• Imports skills and knowledge from a wide range of
  experience

7

• Disadvantages of Standard Software
• Possible mismatch between software solution and
  user requirements
• Limited user privileges to modify software
• Poor performance because of high resource demands
  
• Required interfaces between products may be
  difficult
• Dependency on software manufacturer

8

• The Changing Business Environment
• Mergers
• Government deregulation
• Globalization
• Business process reengineering
• IT Trends
• Client-server technology
• Object-orientation
• Telecomunications
• Internet
• How can custom built legacy systems keep up?
• Can an organisation maintain staff that are
  expert in so many areas?
• How can an organisation reorganise itself within
  the limits imposed by legacy software?
• The adoption of ERP products appears to resolve
  these problems.

9

• ERP Responses to the Changing Business
  Environment
• Reduces workforce in core transaction processing
  systems by eliminating manual tasks and
  duplication.
• Supports global business operations.
• Economies of scale achieved by replacing division
  level systems with corporate level systems
• Reduction of information systems development
  staff
• Improves customer service through better
  logistics based on more complete accessible
  information.
• Data integrity is improved through a common
  database.
• Decision support is improved through more timely
  reports and better drill down capabilities.
• Costs
• 800,000 for a midsize firm (400k - 2 billion
  annual sales)
• 3-8,000,000 for a large corporation (2 billion
  )
• Consulting fees may be high due to shortage of
  staff.
• Payback expected in 6 30 months.

10

• Function Orientation of Standard Software
• Initially developed for well defined functional
  areas (Financial Accounting).
• These solutions were taken up within functional
  areas of Organisations.
• Different software suites were difficult o
  integrate.

11

• Business Process Engineering and Standard
  Software
• Brought changes in organisational structures
• Software continued to be developed along
  functional lines
• Software functions were integrated with common
  data sets it remained function oriented
• Business administration functions provided by
  standard software are across product lines and
  markets hence modules are complex.

12

• Mitigating factors (1)
• Standard software is now highly integrated
• Functionality and data storage may be
  decentralised (client/server)
• Dynamic adaptability (parameterisation)
• Employee oriented, user friendly concept of
  standard software?
• These factors make the use of function oriented
  software in Business processes possible.
• Client/Server model allows data and functionality
  to be distributed as needed.

13

• Mitigating factors (2)
• Parameterisation influences the behaviour of the
  software and can be used to customise standard
  software to match an organisation.
• Adjustments can be made before or during the
  operation of the software.
• Modules can be designed to match current needs
  (by selecting the appropriate components)
• User Exits allow standard software to be
  customised with outside applications.

14

• Key characteristics of modern standard software.
• From Kirchmer p 25

15

• Implementation of Standard Software
• Defined as the sum of all activities necessary to
  effectively utilize software in the business
  environment of a user company. From Kirchmer
• Types of implementation
• Technology centric
• User centric
• Organization centric

16

• Technology centric implementation
• The implementation is viewed as a technological
  task. The organization user requirements are
  those of the software.
• User centric implementation
• Assumes software only gains its desired effect
  when accepted by the users. Only modules
  requested by users are implementged.
• Organization centric implementation
• Software used as a coordinating mechanism for
  modifying the organizational framework of the
  enterprise.
• In this case it must be decided whether to focus
  on the structures in the software or on the
  planned organisational structures of the
  enterprise.

Kirchmer Compare fig 1.12 p 29 fig 1.13 p 30
17
(No Transcript)
18

• Business Process Oriented Implementation of
  Standard Software

COMBINED WITH
Yields
19
(No Transcript)
20

• Business Process Implementation of Standard
  Software
• Views implementation as Organisational
  Development
• Implementation is business driven
• Main goal is to meet the strategic objectives of
  the company.
• Each successive implementation represents the
  implementation of a business process.
• To achieve a process oriented implementation
• Appropriate business processes must be defined.
• Support of these processes must be enabled
  through the software
• Users must be capable of executing the processes
  by means of the software in a way that ensures
  meeting objectives.

21

• ERP Implementation Strategies
• Comprehensive Package
• Fully integrated
• Some particular needs may not be supported
• Lack flexibility to rapid change

22

• ERP Implementation Strategies
• Best-of-breed
• Best software chosen for each application
• Integrate all the applications
• Often the packages dont integrate well
• Middleware (and a skilled systems integrator)
  used to reduce integration problems

23

• ERP Implementation Strategies
• Hybrid
• Some packages purchased due to desirable
  functions
• Comprehensive system provides backbone for rest
  of the system.
• Reduces problems of integration yet allows
  customisation in key areas.

24

• Issues related to standard software vs custom
  software
• Which will provide the most effective information
  system?
• Quality information for better decisions.
• Competitive advantage in rapidly changing
  environment.
• Which will be the most efficient solution?
• Relates to the cost of creating, implementing,
  maintaining and operating the organisations
  information system.

25
Issues relating to purchase Does the package
match the user requirements? How reliable is the
supplier? Is the developer a stable
organisation? Is the package stable or is it
under constant revision? How well does it
integrate with other applications? What support
is available? Are operations staff available?
26

• Issues relating to Implementation and Support
• Customisation
• Changes necessary to meet organisational
  requirements.
• Integration
• How well can they package share information with
  other systems.
• Upgrades
• How often is the software upgraded?
• How is the upgrade affected by customisation and
  integration issues?

27

• Customisation includes
• Configuration
• Modification
• Enhancement

28

• Configuration
• Assembling the purchased modules into a system.
• Setting parameters in the package.
• Adjusting user interfaces.
• Integrating with other packages or systems.

29
Modification Changing the package code to alter
existing processing. This can cause serious
problems when upgrading. The vendor may not
support modification. Original code may be
unavailable.
30

• Enhancement
• Adding functionality to a package.
• Does not alter the original package.

31

• Upgrading
• Upgrading can be a serious problem if extensive
  work was required for customisation or
  integration.
• Integrating Packages
• Packages tend to work separately from
  one-another, but they need to either use, supply
  or share data with other systems.
• Organisations try to set up data so that it is
  accessed in a standardised form in real time.

32

• Selecting a Comprehensive ERP package
• Preliminary evaluation
• Is critical functionality available?
• The up-front costs of the package.
• The cost of ongoing support, upgrades and add ons
• Viability of the vendor.
• The fit between the business model of the package
  and the current processes of the organisation.
• Proven success in the business environment
• Availability of customisation tools.
• Accommodation for the organisations management
  style.

33
Detailed evaluation Lower-level
managers Operating personnel On-Site
visits Sites using the package are visited Sites
identified through own researches Quality of
support performance and reliability are
determined Customisation difficulty
studied Hardware, software and implementation
times are studied
34

• Final Decisions
• Criteria determined
• Weighting assigned
• Total score for each product is determined
• Any serious faults are noted and may disqualify
  product
• Consensus must be achieved with final decision.

35

• Systems Development in an ERP Environment
• Large projects need to be well organised to be
  successful
• Organisational Structure for ERP projects

36

• Oversight committee
• Monitor project
• Make key recommendations
• Representative of all users
• Project Teams workgroups formed
• Teams assigned to different development areas
• Vendor representatives
• Administrative support provided

37

• Phases of development
• Two key factors affect development
• The scope is very large
• Packaged software is used extensively
• Planning
• Oversight committee is formed
• Project team formed
• General purpose and scope determined
• Alternative approaches to ERP evaluated
• Initial selection made
• Determine how the project is to proceed
• Budgets, feasibility, project schedule

38

• Analysis
• Work Groups formed, Requirements determined
• Vendors evaluated, selected, but not finalised
• Business process engineering requirements
  identified
• Prototypes developed to demonstrate integration
• Alternatives reconsidered re-evaluated
• Recommendations presented to Oversight Committee

39

• Question
• Will the analysis phase be longer or shorter than
  that for the custom development approach?

40

• Design
• Varies considerably depending on approach taken
• Interface design varies according to the amount
  of customisation required
• Hardware and networks must support packages
• Training of end-users
• BPR performed, new procedures and job
  descriptions prepared

41

• Implementation
• Configuration of modules
• Integration of packages
• Prototype created and evaluated until production
  ready
• System is verified, tested tuned
• System documentation completed
• User training completed
• New system installed with rollout plan developed
  during design
• Organisational structures changed, personnel
  placed in new positions
• New procedures implemented

42

• Support
• Continued training support
• Well managed Help Desk
• Adaptive corrective maintenance