• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 2
  • Tagged with
  • 2
  • 2
  • 2
  • 2
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
1

Factors influencing the adoption of enterprise application architecture for supply chain management in small and medium enterprises with Capricorn District Municipality

Lamola, Kingston Xerxes Theophilus January 2021 (has links)
Thesis (M.COM. (Business Management)) -- University of Limpopo, 2021 / Increasing consumer demand, customer expectations, and change in technology compel industrial corporations, governments and small medium enterprises (SMEs) to adopt Enterprise Application Architecture (EAA). EAA is a system where the applications and software are connected to each other in such a way that new components can easily be integrated with existing components. This study focused on how internal and external factors impact the adoption of EAA for Supply Chain Management (SCM) in SMEs, located in the Capricorn District Municipality. Data is analysed through a statistical package for the social sciences (SPSS version 25). A quantitative methodology with self-administered questionnaire was used to collect data from SMEs (SMEs owners and managers). In total, 480 questionnaires were distributed and 310 useable were returned. Cronbach’s Alpha was used to measure reliability. Data validity is obtained through the use of Kolmogorov-Sminorv-Test to ensuring that the questionnaire was based on assumptions from accepted theories as set out in the literature review. From the research findings, it was concluded that the adoption of EAA for SCM in SMEs depends on internal factors, external factors and perceived attitudes towards the adoption of EAA. The managerial implications of the study is based on actual results such as; (a) Internal factors on owners’ characteristics were described as assessment of interior dynamics affecting the enterprise, of which the management have a full control over them, such as employees, business culture, norms and ethics, processes and overall functional activities, (b) The Theory of Reasoned Action (TRA) revealed that behavioural measures on Enterprise Resources that depends on speculations about the intensions towards the adoption of EAA for SCM, (c) Compatibility in Diffusion Theory of Innovation ascertains that Technology Acceptance Models need to be linked with relevant Information System Components to have a functional EAA for SCM, (d) The Theory of Planned Behaviour (TPB) encourages apparent behaviour on control for supplementary forecaster on intentions of employees towards the adoption of EAA for SCM in SMEs, (e) The TPB encourages apparent behaviour on control for supplementary forecaster on intentions of employees towards the adoption of EAA for SCM in SMEs, (f) Consultations with government parastatals or legal representatives of the enterprise would save the SMEs against any unforeseen challenges such as product liabilities, legal costs on lawsuit, tax evasion or avoidance penalties so forth, (g) The Diffusion Theory of Innovation (DTI) proposes that the Perceived Attitudes towards the Adoption of EAA have is affected by behaviour challenges from employees’ personal conduct that affect SCM activities within the SMEs, and (h) The DTI on the intention towards the adoption of EAA for SCM provides the competence in limiting some negative thoughts about the integrative phases or steps limiting the adoption of EAA for SCM. Keywords: Enterprise Application Architecture; Supply Chain Management; Internal and External Factors Affecting Adoption; and Technology Acceptance Models
2

RefStratERP – A Refactoring Strategy for ERP Systems

Petkovic, Nikola January 2017 (has links)
Enterprise Resource Planning (ERP) systems are used to integrate all functions of an enterprise. They often evolve from a smaller monolithic object-oriented application, covering one functional area and organically grow over time in features and size until all functional areas are covered. Once they reach certain size, unrestricted dependencies among numerous classes increase complexity of the system and make it harder for development team to create new features and maintain code stability. This creates problems to further evolution of the ERP system and poses a risk to economic consequences for company developing it. ERP refactoring strategy, together with process of its creation, is presented in this thesis. It can be used with ERP systems, having architectural issues, with a purpose to improve quality of system’s architecture and thus prolong its lifecycle. The goal of modularizing monolithic system it pursued with intention to reduce complexity and make it easier to reason about the system. This architecture-level refactoring strategy is created for one specific medium-sized ERP system through iterative trial-and-error explorative approach. This thesis is carried out at the main development site for this ERP system by project team consisting of employees working on its development. The result shows the RefStratERP, an innovative refactoring strategy consisting of target architecture, refactoring process to reach it, refactoring principles and refactoring limitations. Contrary to initial expectation, arranging domain modules (modules containing business logic) in directed acyclic graph (DAG) is, in general, not feasible without sacrificing internal module cohesion of business logic. Accidental unidirectional dependency between two domain modules is at risk of becoming bidirectional under changing business requirements. On the other hand, non-domain modules (modules without business logic) could be completely separated from domain modules in a way that domain modules depend on non-domain modules. This comes from underlying nature of business domain and the fact that functional areas of an enterprise are interdependent. / Enterprise Resource Planning-system (ERP) används för att integrera alla funktioner inom ett företag. Oftast utvecklas dem från en mindre monolitisk objektorienterad applikation som täcker ett funktionellt område och växer organiskt över tiden i funktioner och storlek tills alla funktionella områden är täckta. När dem når en viss storlek ökar komplexiteten i systemet vilket gör det svårare fär utvecklingsteamet att skapa nya funktioner och hålla kodstabilitet. Detta skapar problem för fortsatt utveckling av ERP-systemet och utgör en risk för ekonomiska konsekvenser för utvecklingsföretaget. ERP refactoringstrategin, tillsammans med processen med att skapa den, presenteras i denna avhandling. Den kan användas med ERP-system, med arkitektoniska problem, med syfte att förbättra kvaliteten hos systemets arkitektur och därigenom förlänga dess livscykel. Målet att modularisera monolitiska system strävas efter i syfte att minska komplexiteten och göra det lättare att resonera kring systemet. En refaktorstrategi på arkitektnivå skapas för ett specifikt medelstort ERP-system genom en iterativ och försök-och-mistag-explorativ metod. Projektet genomfördes på ERPs huvudutvecklingsplats av ett projektteam bestående av anställda inom ERP utveckling. Resultatet visar RefStratERP, en innovativ refaktorstrategi som består av målarkitektur, refactoringprocess för att nå det, refactoringprinciper och refactoringbegränsningar. I motsats till inledande förväntningar är det i allmänhet inte möjligt att ordna domänmoduler (moduler som innehåller affärslogik) i en riktad acyklisk graf (DAG) utan att påverka interna modulsammanhang (cohesion) i affärslogiken. Oavsiktlig enriktad beroende mellan två domänmoduler riskerar att bli dubbelriktad under förändrade affärsbehov. Å andra sidan kan icke-domänmoduler (moduler utan affärslogik) helt separeras från domänmoduler så att domänmoduler beror på icke-domänmoduler. Detta kommer från underliggande egenskaper av affärsområden och det faktum att verksamhetsområden inom ett företag är beroende av varandra.

Page generated in 0.1245 seconds