Item gefilterd op datum: mei 2014

->
Having defined the outcome of interest, we need a theory to explain it.

• Rational actor (bv. technology acceptance model), it highlight peoples motivations and the actions they take to achieve their goals.
• External control theory, externe krachten
• Emergent process, interacties tussen mensen in organisaties en omgevingen

->
We build our framework on a particular emergent process theory designed by Soh and Markus toexplain how information technology creates (or fails to create) business value. Dit model komt overeen met de laatste 3 fasen uit de “Experience Cycle”.

Success is the key-outcome of interest in our framework. The definition of success outcome:
• Multidimensional (Verschillende afdelingen)
• Dynamic concept (Dynamisch, wat je nu vindt hoeft niet over een half jaar nog zo te zijn)
• Relative (tijd)

There is a lack of consensus and clarity about the meaning of success.

Based on our observations of enterprise systems projects, we argue that a minimum set of success metrics includes the fellowing:

1. Project metrics
2. Early Operational Matrics
3. Longer-Term Business Metrics

To accommodate the multidimensionality and relativity of enterprise system success from the adopting organization’s perspective, we define a standard of optimal success, which refers to the best outcomes the organization could achieve with enterprise systems, give its business situation measured against a portfolio of project, early operational, and longer-term business results metrics.

1. Lack of “feature function fit”
2. Organisatie grootte, Strategische flexibiliteit, Decentralized decision-making style (Dell)
3. Toegankelijkheid van alternatieven (Data warehouse system, BI, middleware)
4. Costs, competitive advantage, resistance to change

1. Technical reasons (operating costs, Y2K)
2. Business reasons (one face to the customer)

Je hebt bij grote bedrijven te maken met 3 zaken, ten opzichte van kleine bedrijven:
• Fusies en overnames
• Internationaal
• One client vision

1. Integration, Enterprise Systems promise seamless integration of all the information flowing through a company. However, it is extremely important to note that achieving this integration depends on “configuring” (setting up) the system in particular ways.

2. Packages, Enterprise systems are commercial packages. The process of configuring an enterprise system for an organization differs substantially from software programming. Programming (new software functionality), Configuration (adapting the generic functionality of a package to the needs of a particular organization).

3. Best Practices, The vendors of Enterprise Systems have crafted what they claim to be “best practices”. Hier zal zeker BPR mee gepaard gaan, vóór, tijdens of na de implementatie van het system.

4. Some Assembly Required, At one level, the claim of enterprise systems to be “integrated” is wildly overstated. What is integrated is the software, not the computing platform on which it runs.

5. Evolving, Like all of IT enterprise systems are rapidly changing. Zowel op het gebied van architectuur, functionaliteit en de service die de systemen te bieden hebben.

• 
  Internal People (Business process ingineers, Operations, support, IT professionals)
  
  
• External People
  
  
• Project Roles

Week 3, The Enterprise System Experience – From Adoption to Succes (Markus & Tanis)

It takes years at best to realize some envisioned IT-enabled changes in organizational processes and
performance, and there are many ways to fail along the way. Om deze reden wordt er gekeken in dit
artikel naar Experience.

• 
  Direct Cutover (old – new)
• 
  Parallel Transition (old parallel aan nieuw, heel duur)
  
  
• Phased Transition (Gefaseerd, eis: niet veel cross functionele processen)
  
  
• Pilot Transition (Een pilot draaien)

-> Installation

System landscape, is een term voor een onafhankelijk systeem dat wordt gebruikt voor ontwikkeling, configureren, testen en maakt een ERP operationeel. Het kan worden geïnstalleerd op 1 machine of server, of het kan verspreid worden over verschillende servers.


-> Configuration

Dit is een algemene term dat inhoud het ES te modificeren om zo de specifieke business processen, structuur en data benodigdheden van een specifieke organisatie te ondersteunen. Centralized procurement en decentralized procurement.


-> Interface to Lagacy Systems

Inbound interfaces zijn programma’s die inkomende data converteren naar het gewenste formaat van het ES. Outbound interfaces zijn interfaces die data van het ES pakken en die omzetten naar gebruikte formaten van de oude systemen. Zo kan er dus tussen beide gecommuniceerd worden tijdens een gefaseerde implementatie.


-> Customized Forms, Reports, and Screen Lay-outs

Alhoewel veel leveranciers het afraden, wordt dit gedeelte vaak gedaan door kleinere programmeurs. Hierdoor is het in de toekomst weer makkelijker aan te passen.


-> Authorizations

Wie heeft toegang tot welke informatie in het systeem. Iedere gebruiker wordt geplaatst in een gebruikersgroep. Het systeem dient hierin ook flexibel te zijn, bij bijvoorbeeld iemand die promoveert en toegang krijgt tot meerdere gebieden.


Modifications, Add-ons, and Bolt-ons

Dit wordt vaak in-huis gedaan. Dit soort aspecten worden ingebracht om het ERP pakket uit te breiden.

-> Data Conversion

->
Testing

->
Uncovering the “As is” picture – Analyzing Existing Processes.

- Change Management Requirements


-> Creating the “To be” picture – Business Process Redesign.

Business Proces Redesign kan zonder de implementatie van ERP, maar de implementatie van een ERP kan niet zonder BPR. Er kunnen veel verschillende methoden worden gebruikt om het To Be plaatjes te creëren, echter heeft elke methode overeenkomende elementen. 1). Een notie van klant focus, 2). De uitkomst van het proces is genomen in waarde ontvangen door de klant of aandeelhouder, 3). Een cross- functioneel team is nodig zodat iedereen alle aspecten begrijpt van het totale business proces, 4).

Tot slot hebben alle methode een gefaseerde benadering.

Elke auteur zal overeenstemmen met de stelling dat binnen de implementatiefase het onderdeel BPR vaak fout gaat. Mensen gaan er pas goed over nadenken op het moment dat het eigenlijk al te laat is. Met Enterprise Systems, BPR heeft een dubbele rol (dual rol) ‘resultaat’ en ‘voorwaarde’.


-> Analyzing the Gaps.

Twee standaardvragen kunnen worden gesteld tijdens deze analyze, 1). Op welke gebieden moet de organisatie verandering wil het voordeel kunnen behalen met het ERP en 2). Op welke vlakken zal het ERP aangepast dienen te worden om in de unieke functionaliteit van de organisatie te passen.

• 
  Creating the Project Administration
  
• Assembling the Project Staff

Chevron Case, Driving the ERP highway: Chevron corporation and SAP

In deze case wordt beschreven hoe Chevron, na de fusie met Gulf Corporation, zijn business heeft draaien op 200 aparte mainframes (als kleine eilandjes in een zee van verwarring). In 1990 heeft de CFO Marty Klitten onderzoek gedaan en zette een project team op voor de implementatie van het Advanced Financial Information System (AFIS). Het zou tussen de 80 en 100 miljoen dollar gaan kosten en ze zouden het realiseren in samenwerking met SAP. De strategie was om eerst het systeem te implementeren in de minst risicovolle filialen en daarna langzaam het in de totale organisatie implementeren. Ze hebben alles gegroepeerd en deze groepen ook apart trainingen verleend, daarnaast hebben ze ook BPR gerealiseerd binnen de gehele organisatie. Naast dat het succesvol is uitgepakt, zijn ze er wel achtergekomen dat de implementatie van een ERP veel met zich meebrengt. Het heeft meer geld gekost dan begroot, het heeft veel meer invloed gehad op de organisatie dan verwacht en het was een stuk complexer dan ze het zich hadden voorgesteld.

• Setting Goals and Objectives (Identify Business Drivers) Wat zijn de factoren die zorgen voor de verlangens naar een ERP en wat zijn daar de redenen van.
  
• Developing Project Resources
• 
  Establishing Project Metrics