<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE article  PUBLIC "-//NLM//DTD Journal Publishing DTD v3.0 20080202//EN" "http://dtd.nlm.nih.gov/publishing/3.0/journalpublishing3.dtd"><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" dtd-version="3.0" xml:lang="en" article-type="research article"><front><journal-meta><journal-id journal-id-type="publisher-id">JCC</journal-id><journal-title-group><journal-title>Journal of Computer and Communications</journal-title></journal-title-group><issn pub-type="epub">2327-5219</issn><publisher><publisher-name>Scientific Research Publishing</publisher-name></publisher></journal-meta><article-meta><article-id pub-id-type="doi">10.4236/jcc.2019.712011</article-id><article-id pub-id-type="publisher-id">JCC-97447</article-id><article-categories><subj-group subj-group-type="heading"><subject>Articles</subject></subj-group><subj-group subj-group-type="Discipline-v2"><subject>Computer Science&amp;Communications</subject></subj-group></article-categories><title-group><article-title>
 
 
  System Implementation Failures in the ERP Development Process
 
</article-title></title-group><contrib-group><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Samantha</surname><given-names>Mathara Arachchi</given-names></name><xref ref-type="aff" rid="aff1"><sup>1</sup></xref><xref ref-type="corresp" rid="cor1"><sup>*</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Siong</surname><given-names>Choy Chong</given-names></name><xref ref-type="aff" rid="aff1"><sup>1</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Alik</surname><given-names>Kathabi</given-names></name><xref ref-type="aff" rid="aff1"><sup>1</sup></xref></contrib></contrib-group><aff id="aff1"><addr-line>University of Colombo School of Computing (UCSC), Colombo, Sri Lanka</addr-line></aff><pub-date pub-type="epub"><day>28</day><month>11</month><year>2019</year></pub-date><volume>07</volume><issue>12</issue><fpage>112</fpage><lpage>127</lpage><history><date date-type="received"><day>28,</day>	<month>November</month>	<year>2019</year></date><date date-type="rev-recd"><day>24,</day>	<month>December</month>	<year>2019</year>	</date><date date-type="accepted"><day>27,</day>	<month>December</month>	<year>2019</year></date></history><permissions><copyright-statement>&#169; Copyright  2014 by authors and Scientific Research Publishing Inc. </copyright-statement><copyright-year>2014</copyright-year><license><license-p>This work is licensed under the Creative Commons Attribution International License (CC BY). http://creativecommons.org/licenses/by/4.0/</license-p></license></permissions><abstract><p>
 
 
  ERP mainly relates to business management software which consists of several modules that are important for the growth and survival of different types of businesses and organisations. The integration of related business applications in an organisation can bring significant advantages to the business by enabling faster supply chain management. ERP implementation enables firms to adapt and configure information flows and integrate business processes in order to enhance business performance. System implementation has been reviewed with adequate literature to significantly support the importance of arithmetic and logical concepts and basic errors in programming including typographical errors in a programme, identification of syntax errors and programme output process errors. It has further discussed the variables declaration, significance of modularization and necessity of supporting accessories along with the usability of library files and the importance of the use of frameworks. Enhancement of coding formatting and significance of coding syntax were also critically reviewed with sufficient literature to identify the system implementation failures in the ERP development process.
 
</p></abstract><kwd-group><kwd>System</kwd><kwd> Implementation</kwd><kwd> Programming</kwd><kwd> Failures</kwd><kwd> ERP</kwd><kwd> Factors</kwd><kwd> Framework</kwd></kwd-group></article-meta></front><body><sec id="s1"><title>1. Introduction of System Implementation</title><p>ERP implementation is not an easy task for either the implementation team or the firm. It has to be carried out by a competent group of technical experts with a well-defined plan as it is a complex and expensive process to be carried out. Although it is a difficult task [<xref ref-type="bibr" rid="scirp.97447-ref1">1</xref>], most organisations are compelled to implement ERP systems as it can facilitate both productivity and efficiency of the current and future organisational business processes [<xref ref-type="bibr" rid="scirp.97447-ref2">2</xref>].</p><p>Selecting a programming language for implementation is a main task in the ERP context and ERP customisation does not have a lesser value attached to it. Therefore, this procedure has to be followed with much care and there are many facets to be considered, such as selecting a good programming language, designing methodology and using the correct tools [<xref ref-type="bibr" rid="scirp.97447-ref3">3</xref>]. When selecting a good programming language to implement ERP systems, there are many variables that need to be considered [<xref ref-type="bibr" rid="scirp.97447-ref4">4</xref>]. Considering the ERP capabilities and the rapid advancements of technology, high-performance computing, web services support and service-oriented architecture (SOA) are the key areas when evaluating a suitable programming language [<xref ref-type="bibr" rid="scirp.97447-ref5">5</xref>] [<xref ref-type="bibr" rid="scirp.97447-ref6">6</xref>].</p></sec><sec id="s2"><title>2. Considered Factors in Implementing</title><p>There are eight subdomains in this component. They are, arithmetic and logical concepts (ALC), basic errors in system implementation (BESI), programme output process errors (POPE), variables declaration (VD), modularisation (MO), supporting accessories (SA), coding formatting (CF) and coding syntax (CS).</p><sec id="s2_1"><title>2.1. Arithmetic and Logical Concepts (ALC)</title><p>Algorithms are constructed using arithmetic and logical concepts. They are step-by-step finite sequences of instructions to solve a well-defined computational problem. Algorithms are used to solve any complex real-life problems visible in the industry when implementing an ERP system. Hence, it is very important to design the algorithm to solve the problem while writing and executing programmes to get the expected output. There are two approaches for algorithm design, namely the top-down and the bottom-up algorithm designs [<xref ref-type="bibr" rid="scirp.97447-ref7">7</xref>].</p><p>When automating business scenarios, there are logical concepts that need to be fulfilled to complete the flow of business. All these logics must be constructed accurately. If not, the ERP failure rate could be high, giving wrong or unrealistic outputs [<xref ref-type="bibr" rid="scirp.97447-ref7">7</xref>]. According to Donald’s theory [<xref ref-type="bibr" rid="scirp.97447-ref8">8</xref>], some of the causes leading to high ERP failure rate are as follows: branching performed incorrectly, loop terminations not defined well-violated programming language rules violated programming standards and misinterpreted language constructs by the programmers. The recognition of arithmetic algorithms overcomes the shortcomings of some typical current approaches and introduces logical correlation matrices as a solution to the logic diagrams. In addition, a dynamic pruning policy that offers a specific instance is executed and also the complexity analyses which proves the validity and sophistication of the new arithmetic separately [<xref ref-type="bibr" rid="scirp.97447-ref9">9</xref>]. These concepts are important to avoid inadequate decision logic, arithmetic computations, and erroneous arithmetic computations.</p></sec><sec id="s2_2"><title>2.2. Basic Errors in Programming (BESI)</title><p>In programming, different types of errors can occur. They are typographical errors such as syntax errors, data errors and programme output errors [<xref ref-type="bibr" rid="scirp.97447-ref10">10</xref>]. These errors are explained in the following sub-sections as follows: 1) Typographical Errors in a Programme [<xref ref-type="bibr" rid="scirp.97447-ref11">11</xref>], 2) Syntax Errors [<xref ref-type="bibr" rid="scirp.97447-ref12">12</xref>], 3) Programme Output Process Errors [<xref ref-type="bibr" rid="scirp.97447-ref13">13</xref>] [<xref ref-type="bibr" rid="scirp.97447-ref14">14</xref>].</p><p>The following errors should be remembered and addressed, when necessary, to fix the bugs in the application: 1) identified indexing errors; 2) violated parameters or subscripts; 3) identified data errors; 4) identified non-terminating sub-programmes; 5) identified disk handling errors; 6) identified output processing errors; 7) identified iterative; 8) procedural errors; and 9) identified initialisation errors.</p><p>Document management is very important to the software industry and needs to be maintained well to identify the errors in programming. However, the techniques of document management are applicable with little modification across a wide variety of disciplines, including software. These documents should be modified along with design changes as quickly as possible. Formatting, checking spelling and grammar, organising content and flow of content and also maintaining templates are advisable to make retrieval easy. It should include memos, recipients, and details of senders as well [<xref ref-type="bibr" rid="scirp.97447-ref15">15</xref>]. At its simplest, document management has usually been considered to cover the techniques of creating and or acquiring, storing, locating and retrieving documents throughout their life cycle. However, as the use of computers has increased, documents have increasingly become available. Electronically, the remit of document management has evolved to a point where a “document” can be virtually any sort of computer file, a spreadsheet, a graphics file, a scanned image, a video clip, a voice-mail message and so on [<xref ref-type="bibr" rid="scirp.97447-ref15">15</xref>].</p></sec><sec id="s2_3"><title>2.3. Variables Declaration (VD)</title><p>Variables play an important role in computer programming because they enable programmers to write flexible programmes. Rather than entering data directly into a programme, a programmer can use variables to represent the data. When the programme is executed, the variables are replaced with real data. This makes it possible for the same programme to process different sets of data [<xref ref-type="bibr" rid="scirp.97447-ref16">16</xref>]. Every variable has a name, designated as the variable name, and a data type. A variable data type indicates what sort of value the variable represents. The opposite of a variable is a constant. Constants are values that never change. Because of their inflexibility, constants are used less often than variables in programming [<xref ref-type="bibr" rid="scirp.97447-ref16">16</xref>].</p></sec><sec id="s2_4"><title>2.4. Modularisation (MO)</title><p>Modularisation programming is a software design technique that emphasizes on separating the functionality of a programme into independent, interchangeable modules [<xref ref-type="bibr" rid="scirp.97447-ref17">17</xref>], especially when automating a complex business process like an ERP application. It maintains an easy and clear way to minimise the error rate of the application. In addition, it gives a clear overview of the application [<xref ref-type="bibr" rid="scirp.97447-ref18">18</xref>].</p></sec><sec id="s2_5"><title>2.5. Supporting Accessories (SA)</title><p>Nowadays, in programming, there are supporting applications, objects, classes and many more readymade sets of codes that can be incorporated with the existing codes. This is an advantage rather than constructing a programme from scratch. The usability of library files and the importance of use of frameworks are identified as separate types as described in the following sub-sections: 1) Usability of Library Files [<xref ref-type="bibr" rid="scirp.97447-ref19">19</xref>], 2) Use of Frameworks [<xref ref-type="bibr" rid="scirp.97447-ref20">20</xref>] [<xref ref-type="bibr" rid="scirp.97447-ref21">21</xref>] [<xref ref-type="bibr" rid="scirp.97447-ref22">22</xref>].</p></sec><sec id="s2_6"><title>2.6. Coding Formatting (CF)</title><p>Coding formatting enhances the readability of lengthy programming and eases the identification of the errors or bugs when fixing bugs. Especially when control structures are used, it is important to format the code and align them properly by using tabs for indentation, without using both tabs and spaces because not all text editors treat tabs as exactly eight spaces and also leave only one blank line between subroutines to limit blank lines in the programme [<xref ref-type="bibr" rid="scirp.97447-ref23">23</xref>].</p></sec><sec id="s2_7"><title>2.7. Coding Syntax (CS)</title><p>The programming language syntax, which forms part of a larger analysis of different programming languages, has been identified to be able to reduce the gap between programming languages [<xref ref-type="bibr" rid="scirp.97447-ref24">24</xref>]. Code syntaxes are the most powerful, which provides the grammar to write a programme. If the syntax is wrong or is misused, the programme will not execute properly and it will take two to three minutes to even days to recover, even if a colon or a semicolon is missing. It could become a major issue or mislead output [<xref ref-type="bibr" rid="scirp.97447-ref14">14</xref>]. To address this problem, the following rules are recommended to be adopted: 1) use shift operators instead of multiplication for constructing bit patterns; 2) always check for default case in switch statement; 3) use each variable for one purpose only; 4) use each field of structure for one purpose only; 5) avoid using global variables within outlines; 6) avoid using nonlocal variables within routines; 7) declare each variable in the smallest scope possible; 8) include all syntax errors to reduce the failure rate; and 9) correct errors promptly as they occur to keep the code simple [<xref ref-type="bibr" rid="scirp.97447-ref23">23</xref>] [<xref ref-type="bibr" rid="scirp.97447-ref25">25</xref>].</p><p>In addition, the data visualisation technique also helps to reduce the dimensions of data through the use of self-organising neutral networks. Manually generated programming codes as well as automated programming codes show similarities between them and are computed to get a generalised meaning of the syntax trees for the non-vectorial self-organising maps model [<xref ref-type="bibr" rid="scirp.97447-ref22">22</xref>].</p></sec></sec><sec id="s3"><title>3. Methodology</title><sec id="s3_1"><title>3.1. Research Framework</title><p><xref ref-type="fig" rid="fig1">Figure 1</xref> shows the research framework for this study. The proposed framework comprises two constructs: (1) ERP systems implementation (6) programming language.</p><p>The independent variables consist of ERP systems implementation. Systems implementation is the construction of the new system and the delivery of that system into output using a computer programme [<xref ref-type="bibr" rid="scirp.97447-ref26">26</xref>].</p><p>The mediating variable is a programming language that can be selected according to the type of application or convenience of the developer [<xref ref-type="bibr" rid="scirp.97447-ref22">22</xref>]. ERP failure rate represents the dependent variable.</p></sec><sec id="s3_2"><title>3.2. Hypotheses Development</title><p>The proposed research framework broadly depicts the possible relationships connecting the two constructs. To substantiate these relationships, the literature was explored to discover the theoretical evidence upon which the hypothetical relationships connecting the constructs were built. These relationships have been planned as a set of research hypotheses addressing the research questions. The following two hypotheses were developed based on the research objectives and research framework:</p><p>H1: There is a significant relationship between system implementation and ERP failure.</p><p>H2: Programming languages significantly mediate the relationship between system implementation and ERP failure.</p></sec><sec id="s3_3"><title>3.3. Research Method</title><p>A quantitative approach was adopted in this study. It is a normative survey approach and evaluation which is commonly used to explore the opinions of respondents who represent the whole population. The quantitative approach is more appropriate for this study since the objectives were to identify factors leading to ERP failure [<xref ref-type="bibr" rid="scirp.97447-ref27">27</xref>]. This method describes the nature of a condition as it takes place during the time of the study and explores the system or systems of a particular condition at each and every stage of the SDLC. In addition, the method is appropriate because it enables the researcher to generalise the findings obtained [<xref ref-type="bibr" rid="scirp.97447-ref28">28</xref>]. The constructs in the questionnaire were identified based on relevant literature, as well as the challenges and the concepts cited by respondents during the pre-survey. The questionnaires were self-administered.</p></sec><sec id="s3_4"><title>3.4. Study Setting</title><p>The researcher has examined the ERP development companies under the Companies Registration Act of Sri Lanka and found that such development work is undertaken by such companies registered under the Board of Investment (BOI) and the Public Limited Companies (PLC) Act of Sri Lanka. However, the software development companies registered under the PLC Act were not considered in this study due to their lack of investment capacity and involvement of ERP application development [<xref ref-type="bibr" rid="scirp.97447-ref29">29</xref>]. In addition, the PLCs do not have enough capital and resources as well as bank guarantee when signing vendor agreements. Hence, they are not engaged in developing total solutions for ERP applications. There are some companies that are registered under the BOI but have less than twenty employees, making little investments and having less capital. These companies were omitted as well.</p></sec><sec id="s3_5"><title>3.5. Unit of Analysis</title><p>The unit of analysis consists of employees engaged in developing ERP applications at each and every stage of the software implementation in software development companies in Sri Lanka. The respondents were selected using a stratified sampling method by considering staff members with similar educational qualifications and working experience. Under this sampling method, each member of a population has an equal opportunity to become part of the sample based on the levels of developers prescribed. Since all of the employees have an equal chance of becoming research participants, this sampling method is said to be the most efficient sampling procedure [<xref ref-type="bibr" rid="scirp.97447-ref30">30</xref>]. A total of 48 software development companies registered under BOI qualified for this study. In the sampling strategy, the researcher obtained a list of all the employees and selected the sample accordingly software implementation.</p></sec><sec id="s3_6"><title>3.6. Sample Design</title><p>According to the statistics of BOI, there were 66 companies registered for BOI software development projects [<xref ref-type="bibr" rid="scirp.97447-ref31">31</xref>]. Based on the justifications mentioned in the study setting, only 48 companies fulfilled the inclusion criterion. In all of the 48 companies, there were a total of 3640 employees. In the study, the representative sample was selected using a stratified sampling technique to select the employees followed by applying the random sampling approach to distribute the questionnaires. A stratum in this study is a subset of the population that shares at least one of the following common characteristic which is Software Implementers (SI)—everyone performing the same job role must have the same academic qualifications. The sample of 188 out of the 3640 employees has been used in the programming or developing the domain. The survey questionnaire is the research instrument consisting of a series of questions and other prompts for the purpose of gathering information from respondents and records their answers.</p></sec></sec><sec id="s4"><title>4. Data Analysis</title><sec id="s4_1"><title>4.1. Hypothesis 1: There Is a Significant Relationship between System Implementation and ERP Failure</title><p>The quality of system implementation is directly related to ERP failure. Accordingly, if system implementation is not being carried out appropriately, this could cause ERP failure and vice-versa. <xref ref-type="table" rid="table1">Table 1</xref> shows the results of the multiple</p><table-wrap id="table1" ><label><xref ref-type="table" rid="table1">Table 1</xref></label><caption><title> Result of multiple regression for system implementation</title></caption><table><tbody><thead><tr><th align="center" valign="middle"  rowspan="2"  >Independent Variables</th><th align="center" valign="middle"  colspan="2"  >Unstandardised Coefficients</th><th align="center" valign="middle" >Standardised Coefficients</th><th align="center" valign="middle"  rowspan="2"  >T</th><th align="center" valign="middle"  rowspan="2"  >Sig.</th><th align="center" valign="middle"  rowspan="2"  >VIF*</th></tr></thead><tr><td align="center" valign="middle" >B</td><td align="center" valign="middle" >Std. Error</td><td align="center" valign="middle" >Beta</td></tr><tr><td align="center" valign="middle" >(Constant)</td><td align="center" valign="middle" >0.341</td><td align="center" valign="middle" >0.144</td><td align="center" valign="middle" ></td><td align="center" valign="middle" >2.364</td><td align="center" valign="middle" >0.019</td><td align="center" valign="middle" ></td></tr><tr><td align="center" valign="middle" >ALC</td><td align="center" valign="middle" >0.171</td><td align="center" valign="middle" >0.027</td><td align="center" valign="middle" >0.299</td><td align="center" valign="middle" >6.440</td><td align="center" valign="middle" >0.000</td><td align="center" valign="middle" >1.847</td></tr><tr><td align="center" valign="middle" >BESI</td><td align="center" valign="middle" >0.144</td><td align="center" valign="middle" >0.031</td><td align="center" valign="middle" >0.240</td><td align="center" valign="middle" >4.674</td><td align="center" valign="middle" >0.000</td><td align="center" valign="middle" >2.257</td></tr><tr><td align="center" valign="middle" >POPE</td><td align="center" valign="middle" >0.139</td><td align="center" valign="middle" >0.030</td><td align="center" valign="middle" >0.199</td><td align="center" valign="middle" >4.568</td><td align="center" valign="middle" >0.000</td><td align="center" valign="middle" >1.637</td></tr><tr><td align="center" valign="middle" >VD</td><td align="center" valign="middle" >0.052</td><td align="center" valign="middle" >0.023</td><td align="center" valign="middle" >0.086</td><td align="center" valign="middle" >2.215</td><td align="center" valign="middle" >0.028</td><td align="center" valign="middle" >1.282</td></tr><tr><td align="center" valign="middle" >MO</td><td align="center" valign="middle" >0.110</td><td align="center" valign="middle" >0.020</td><td align="center" valign="middle" >0.196</td><td align="center" valign="middle" >5.560</td><td align="center" valign="middle" >0.000</td><td align="center" valign="middle" >1.062</td></tr><tr><td align="center" valign="middle" >SA</td><td align="center" valign="middle" >0.067</td><td align="center" valign="middle" >0.025</td><td align="center" valign="middle" >0.121</td><td align="center" valign="middle" >2.693</td><td align="center" valign="middle" >0.008</td><td align="center" valign="middle" >1.733</td></tr><tr><td align="center" valign="middle" >CF</td><td align="center" valign="middle" >0.057</td><td align="center" valign="middle" >0.024</td><td align="center" valign="middle" >0.104</td><td align="center" valign="middle" >2.341</td><td align="center" valign="middle" >0.020</td><td align="center" valign="middle" >1.700</td></tr><tr><td align="center" valign="middle" >CS</td><td align="center" valign="middle" >0.161</td><td align="center" valign="middle" >0.026</td><td align="center" valign="middle" >0.219</td><td align="center" valign="middle" >6.287</td><td align="center" valign="middle" >0.000</td><td align="center" valign="middle" >1.042</td></tr></tbody></table></table-wrap><p>VIF = Variance Inflation Factor.</p><p>regression analysis between system implementation (SI) as represented by its subdomains of ALC, BESI, POPE, VD, MO, SA, CF, CS and ERP failure (ERPF) according to the data collected.</p><p><xref ref-type="table" rid="table1">Table 1</xref> shows that the p-value for ALC, BESI, POPE, VD, MO, SA, CF and CS was less than 0.05. Hence, SI depends on ALC, BESI, POPE, VD, MO, SA, CF and CS. The R-square value was 0.799, which means that 79.9% of the variation in SI is explained by ALC, BESI, POPE, VD, MO, SA, CF and CS. The value of the VIF was less than 5 and hence, there is no problem of multicollinearity. In terms of residual diagnostics, the residuals were independent and normally distributed. The Kolmogorov-Smirnov test of normality on the residuals showed a p-value of 0.049, which is close to 0.05. Thus, the assumption of normality of the residual terms is met. The equation has been constructed as follows:</p><p>The Equation:</p><p>SI = 0.538 (Constant) + 0.164 (ALC) + 0.135 (BESI) + 0.114 (POPE) + 0.025 (VD) + 0.155 (MO) + 0.051 (SA) + 0.077 (CF) + 0.122 (CS).</p><p>In stepwise regression, only income was significant. The R-square value was 0.999, which means 99.9% of the variation in SI is explained by ALC, BESI, POPE, VD, MO, SA, CF and CS.</p><p>The Equation:</p><p>SI = 0.004 (Constant) + 0.147(ALC) + 0.206 (BESI) + 0.146 (POPE) + 0.083 (VD) + 0.085 (MO) + 0.061 (SA) + 0.084 (CF) + 0.186 (CS)</p><p>According to the above result, the hypothesis one has explained that there is a significant relationship between system implementation and ERP failure.</p></sec><sec id="s4_2"><title>4.2. Hypothesis Testing 2: Programming Languages Significantly Mediates the Relationship between System Implementation and ERP Failure</title><p>The programming languages are posited to have a significant mediating effect on the relationship between SI and ERPF. Hence, the mediating effect of PL between SI and ERPF is illustrated in <xref ref-type="fig" rid="fig2">Figure 2</xref>.</p><p><xref ref-type="table" rid="table2">Table 2</xref> presents the results of the multiple regression analysis on the relationship between SI and ERPF as mediated by PL, while <xref ref-type="table" rid="table3">Table 3</xref> presents the results of PL upon SI.</p><p>The score of the Sobel test was 2.4683904 with a significant p-value is 0.0135722, which is less than 0.05. The finding implies that PL is a significant mediator in the relationship between SI and ERPF as shown in <xref ref-type="fig" rid="fig3">Figure 3</xref>.</p><p>z = a b ( b 2 S E a 2 ) + ( a 2 S E b 2 )</p><p>Based on the above formula, a is the regression coefficient for the relationship between the independent variable and the mediator, b is the regression coefficient for the relationship between the mediator and the dependent variable, SE<sub>a</sub> is the standard error of the relationship between the independent variable and</p><table-wrap id="table2" ><label><xref ref-type="table" rid="table2">Table 2</xref></label><caption><title> Result of multiple regression analysis between system implementation and ERP failure as mediated by programming languages</title></caption><table><tbody><thead><tr><th align="center" valign="middle"  colspan="7"  >Coefficients<sup>a</sup></th></tr></thead><tr><td align="center" valign="middle"  colspan="2"   rowspan="2"  >Model</td><td align="center" valign="middle"  colspan="2"  >Unstandardised Coefficients</td><td align="center" valign="middle" >Standardised Coefficients</td><td align="center" valign="middle"  rowspan="2"  >t</td><td align="center" valign="middle"  rowspan="2"  >Sig.</td></tr><tr><td align="center" valign="middle" >B</td><td align="center" valign="middle" >Std. Error</td><td align="center" valign="middle" >Beta</td></tr><tr><td align="center" valign="middle"  rowspan="3"  >1</td><td align="center" valign="middle" >(Constant)</td><td align="center" valign="middle" >−0.003</td><td align="center" valign="middle" >0.007</td><td align="center" valign="middle" ></td><td align="center" valign="middle" >−0.397</td><td align="center" valign="middle" >0.692</td></tr><tr><td align="center" valign="middle" >SI</td><td align="center" valign="middle" >0.702</td><td align="center" valign="middle" >0.003</td><td align="center" valign="middle" >0.999</td><td align="center" valign="middle" >359.678</td><td align="center" valign="middle" >0.000</td></tr><tr><td align="center" valign="middle" >PL</td><td align="center" valign="middle" >0.182</td><td align="center" valign="middle" >0. 056</td><td align="center" valign="middle" >0.001</td><td align="center" valign="middle" >0.299</td><td align="center" valign="middle" >0.765</td></tr></tbody></table></table-wrap><p><sup>a</sup>Dependent Variable: ERPF.</p><table-wrap id="table3" ><label><xref ref-type="table" rid="table3">Table 3</xref></label><caption><title> Result of multiple regression of programming language upon system implementation</title></caption><table><tbody><thead><tr><th align="center" valign="middle"  colspan="9"  >Coefficients<sup>a</sup></th></tr></thead><tr><td align="center" valign="middle"  colspan="2"   rowspan="2"  >Model</td><td align="center" valign="middle"  colspan="2"  >Unstandardized Coefficients</td><td align="center" valign="middle" >Standardized Coefficients</td><td align="center" valign="middle"  rowspan="2"  >t</td><td align="center" valign="middle"  rowspan="2"  >Sig.</td><td align="center" valign="middle"  colspan="2"  >Collinearity Statistics</td></tr><tr><td align="center" valign="middle" >B</td><td align="center" valign="middle" >Std. Error</td><td align="center" valign="middle" >Beta</td><td align="center" valign="middle" >Tolerance</td><td align="center" valign="middle" >VIF*</td></tr><tr><td align="center" valign="middle"  rowspan="2"  >1</td><td align="center" valign="middle" >(Constant)</td><td align="center" valign="middle" >0.688</td><td align="center" valign="middle" >0.182</td><td align="center" valign="middle" ></td><td align="center" valign="middle" >3.773</td><td align="center" valign="middle" >0.000</td><td align="center" valign="middle" ></td><td align="center" valign="middle" ></td></tr><tr><td align="center" valign="middle" >PL</td><td align="center" valign="middle" >0.702</td><td align="center" valign="middle" >0.185</td><td align="center" valign="middle" >0.776</td><td align="center" valign="middle" >16.125</td><td align="center" valign="middle" >0.000</td><td align="center" valign="middle" >1.000</td><td align="center" valign="middle" >1.000</td></tr></tbody></table></table-wrap><p><sup>a</sup>Dependent Variable: PL.</p><p>the mediator, while SE<sub>b</sub> is the standard error of the relationship between the mediating variable and the dependent variable. The data was applied as follows:</p><p>1) (UnStandardised Beta) a = 1.000; S<sub>a</sub> = 0.003.</p><p>2) b = 0.702; S<sub>b</sub> = 0.185.</p><p>3) c = 0.182; S<sub>c</sub> = 0.056.</p><p>Indirect Effect (IE) = b &#215; c = 0. 702 &#215; 0. 182 = 0.12776</p><p>Variance in IE = (b &#215; S<sub>b</sub>)<sup>2</sup> + (c &#215; S<sub>c</sub>)<sup>2</sup> = (0. 702 &#215; 0. 185)<sup>2</sup> + (0.182 &#215; 0. 056)<sup>2</sup> = 0.016866 + 0.000103 = 0.0169698</p><p>SE in IE 0.0 169698 = 0. 13 0 2</p><p>Z = 0.12776/0.1302 = 0.98112</p><p>The p-value = P [Z &gt; 0.98112] &lt; 0.001 &lt; 0.05</p><p>Thus the indirect effect is significant.</p><p>Using online Sobel application:</p><p>Sobel test statistic: 2.4683904.</p><p>One-tailed probability: 0.006786.</p><p>Two-tailed probability: 0.0135722, this is less than 0.05 and therefore PL is a significant mediating factor.</p><p>Since the p-value is less than 0.05, PL mediates the relationship between SI and ERPF. H6 is accepted.</p></sec><sec id="s4_3"><title>4.3. Findings and Discussion—Hypothesis One</title><p>The first hypothesis was to determine whether there is a relationship between system implementation and ERP failure. It posited that if the system implementation does not do a proper job, this could be a case of failure to the ERP application and vice-versa.</p><p>Variables representing system implementation such as arithmetic and logical concepts (ALC), basic errors in system implementation (BESI), programme output process errors (POPE), variables declaration (VD), modularisation (MO), supporting accessories (SA), coding formatting (CF) and coding syntax (CS) are points of variance that are close to each other in their distribution.</p><p>The mean score for system implementation of ERP applications was 3.70 with a standard deviation of 0.3792. The maximum and minimum scores were 4.58 and 2.83, respectively. The median was 3.80, which indicates that at least 50% of the system developers graded more than 3.80. Thus, the most frequent rating amongst the system developers was 4.00. This shows that the factors identified in the system implementation questionnaire for ERP system design are very important. The constructed framework is shown in <xref ref-type="fig" rid="fig4">Figure 4</xref>.</p><p>The eight clusters shown in <xref ref-type="fig" rid="fig4">Figure 4</xref> include 45 items to represent the relationship between system implementation and ERP Failure, which were confirmed by the tested model of the research. The established testing environment was supposed to fulfill the requirement of all items based on the above eight clusters in the system implementation stage. This demonstrates the high diversity of ERP implementation.</p><p>The correlation coefficient for items for each factor, such as ALC, BESI, POPE, VD, MO, SA, CF, and CS, was represented by p-values as low as 0.028, which are less than 0.05. Thus, the items representing system implementation are significant predictors of ERP failures.</p><p>For every unit increase in ALC, ERP failure is expected to drop by 0.171. For every unit increase in BESI, ERP failure is expected to drop by 0.144, and for every unit increase in POPE, ERP failure is expected to drop by 0.139. For every unit increase in VD, ERP failure is expected to drop by 0.052. Furthermore, for every unit increase in MO, ERP failure is expected to drop by 0.110, and for every unit increase in SA, ERP failure is expected to drop by 0.067. In addition, for every unit increase in CF, ERP failure is expected to drop by 0.057, and for every unit increase in CS, ERP failure is expected to drop by 0.161.</p><p>According to the regression analysis, ALC, BESI, POPE, VD, MO, SA, CF, and CS are the significant predictors that support the objective, i.e. there is a significant relationship between system implementation and ERP failure, and the relationship is in an inverse direction. This implies that the more these factors are being practiced, the lower would be the ERP failure rate.</p><p>The VIF values for ALC, BESI, POPE, VD, MO, SA, CF and CS are 1.847, 2.257, 1.637, 1.282, 1.062, 1.733, 1.700 and 1.042, respectively. Since they are below 5, there is no problem with multicollinearity among these factors.</p><p>The findings show that arithmetic and logical concepts should take into consideration that inadequate decision logic, arithmetic computations, branching performed incorrectly, loop terminations undefined, violated programming language rules and standards, as well as misinterpreted language constructs by the programmers, are the main causes that directly affect ERP failure [<xref ref-type="bibr" rid="scirp.97447-ref7">7</xref>].</p><p>In addition, this study has also confirmed that basic errors in system implementation include typographical, syntax, indexing, data, disk handling, output processing, iterative procedural, initialisation and violated parameters or subscripts, as well as non-terminating sub-programmes are factors that increase the ERP failure rate [<xref ref-type="bibr" rid="scirp.97447-ref10">10</xref>]. Donald [<xref ref-type="bibr" rid="scirp.97447-ref14">14</xref>] also found that programme output process errors play the main role in order to reduce the ERP failure rate. These include errors such as input-output format, main storage allocation, identified software interface and identified erroneous “error message” processing, database interface errors, user interface errors [<xref ref-type="bibr" rid="scirp.97447-ref13">13</xref>] and compiler errors.</p><p>According to Andrei [<xref ref-type="bibr" rid="scirp.97447-ref11">11</xref>] and [<xref ref-type="bibr" rid="scirp.97447-ref16">16</xref>], the necessity of the declaration of a variable is very important. The variable type and dimensions should not be incorrectly declared while unique names for variables and standard naming methods for library files should be meaningful. In addition to this modularization, precautions such as including codes within the main() routine, limiting the number of lines in a routine to 50 or less, having subroutines or loops without duplication of codes are also supposed to reduce ERP failure.</p><p>Then the value of the following items formatting programming code such as tabs and spaces for indentation, a consistent indentation pattern for a programme’s control structure, and limiting blank lines in programmes, which were identified by Chris [<xref ref-type="bibr" rid="scirp.97447-ref23">23</xref>] and was also confirmed by this research. In addition, the researcher also found that coding syntax with the use of shift operators instead of multiplication for constructing bit patterns, switch statement, check for default case, using each variable for exactly one purpose, avoiding using global variables within routines and nonlocal variables within routines, declaring each variable in the smallest scope possible, correcting errors promptly as they occur, as well as keeping code simple were important to enhance the success of the ERP system [<xref ref-type="bibr" rid="scirp.97447-ref12">12</xref>].</p><p>The first hypothesis of this research has been examined through H5 which includes eight clusters along with the 48 items. The findings showed that there is a relationship between system implementation and ERP failure. If a proper system implementation is not carried out, then the ERP failure rate will be high. Therefore, to reduce the failure rate, system implementation has to be carried out according to the research framework proposed in this study.</p><p>There are consistent findings as well for this phase of system implementation. According to [<xref ref-type="bibr" rid="scirp.97447-ref32">32</xref>], ERP implementation is the ability of the firm to adapt and configure information flows and integrate business processes in order to enhance business performance. Considering the ERP back capabilities and the rapid advancements of technology, high-performance computing, web services support, and service-oriented architecture will be the key areas when evaluating a suitable programming language to implement an ERP [<xref ref-type="bibr" rid="scirp.97447-ref5">5</xref>] [<xref ref-type="bibr" rid="scirp.97447-ref6">6</xref>]. The method that generates the syntax tree and uses the feature tree to match the knowledge in the syntax tree to identify code knowledge automatically is being widely followed [<xref ref-type="bibr" rid="scirp.97447-ref12">12</xref>]. The experimental results show that the system can effectively and accurately gather the statistic of knowledge in the programme code in real-time.</p><p>If the input programme covers the whole range of the language syntax constructs, then the parser corresponding to the generated annotated grammar is able to parse and transform into an Abstract syntax tree (AST) any programme of the given language [<xref ref-type="bibr" rid="scirp.97447-ref11">11</xref>]. It is important to use code review correctly. Formatting, spell check and grammar, organising content and flow of content and maintaining templates are advisable. In order to retrieve them, it should include memos and the details of recipients and senders as well [<xref ref-type="bibr" rid="scirp.97447-ref15">15</xref>].</p><p>The results also showed that misusing or improper use of arithmetic and logical concepts, including inadequate decision logic, arithmetic computations, branching performed incorrectly, loop terminations undefined, violated programming language rules and, standards, misinterpreted language constructs by the programmer are the main causes that directly affect the ERP failure [<xref ref-type="bibr" rid="scirp.97447-ref7">7</xref>]. Zhang [<xref ref-type="bibr" rid="scirp.97447-ref9">9</xref>] has pointed out similar results. In this research, more factors have been considered together to determine their impact. That is, again, a major significant contribution to this research.</p><p>Basic errors in system implementation which include typographical [<xref ref-type="bibr" rid="scirp.97447-ref11">11</xref>], the syntax [<xref ref-type="bibr" rid="scirp.97447-ref12">12</xref>], indexing, data, disk handling, iterative procedural, initialisation and violated parameters or subscripts and also non-terminating sub-programmes are factors that increase the ERP failure rate. Widera [<xref ref-type="bibr" rid="scirp.97447-ref10">10</xref>] has identified the same factors which are needed to enhance the programme. All these scholars have separately explained how to write a programme with the minimum of those errors.</p><p>Consistent with Donald [<xref ref-type="bibr" rid="scirp.97447-ref14">14</xref>], this research found that programme output process errors play the main role in order to reduce the failure rate. This includes the following errors such as input-output format, main storage allocation, identified software interface and identified erroneous “error message” processing, database interface errors, user interface errors [<xref ref-type="bibr" rid="scirp.97447-ref13">13</xref>] and compiler errors.</p><p>According to [<xref ref-type="bibr" rid="scirp.97447-ref11">11</xref>] and [<xref ref-type="bibr" rid="scirp.97447-ref16">16</xref>], a variable declaration with the variable type and dimensions incorrectly declared, unique names for variables used meaningfully and standard naming methods for library files are also imperative. In addition to this modularisation, routine, limit number of lines in a routine to 50 or less, subroutines or loops without duplicate codes also contribute to reducing the ERP failure.</p><p>Chris [<xref ref-type="bibr" rid="scirp.97447-ref23">23</xref>] explains that coding, formatting with the tabs and spaces for indentation, programme’s control structure to follow consistent indentation pattern, and limiting blank lines in the programme were also proved again in this research with regard to all the above factors.</p><p>The researcher found that coding syntax with the use of shift operators instead of multiplication for constructing bit patterns, switching statement, checking for default case, using each variable for exactly one purpose, avoiding using global variables within routines and nonlocal variables within routines, declaring each variable in the smallest scope possible, correcting errors promptly, as they occur and finally keeping code simple can enhance the success of the system [<xref ref-type="bibr" rid="scirp.97447-ref12">12</xref>].</p></sec><sec id="s4_4"><title>4.4. Findings and Discussion—Hypothesis Two</title><p>The 2<sup>nd</sup> hypothesis was to determine whether programming languages (PL) mediate the relationship between system implementation and ERP failure. Sobel’s test results showed the value of 2.4683904 with a significant p-value is 0.0135722. This implies that PL is a significant mediator between system implementation (SI) and ERP failure (ERPF).</p><p>The findings are in line with the literature based on the two key points supporting PL as a significant mediator. First, modularisation [<xref ref-type="bibr" rid="scirp.97447-ref17">17</xref>], especially when automating a complex business process like an ERP application It maintains an easy and clear way to minimise the error rate of the application. In addition, it gives a clear overview of the application [<xref ref-type="bibr" rid="scirp.97447-ref18">18</xref>].</p><p>On the other hand, Al-Hossan [<xref ref-type="bibr" rid="scirp.97447-ref33">33</xref>] has also identified that limited access to supporting accessories like library files, frameworks, objects, and modules also increase the ERP failure rate among the software development companies.</p><p>In the 2<sup>nd</sup> hypothsis, modularisation which aligns with the codes within the main() routine, limiting the number of lines in a routine or without duplication codes influencing the relation between system implementation using different programming languages is important to reduce ERP failure [<xref ref-type="bibr" rid="scirp.97447-ref25">25</xref>]. In addition, awareness of supporting accessories such as library files, frameworks, and objectives are also important, while Zimin [<xref ref-type="bibr" rid="scirp.97447-ref17">17</xref>] and [<xref ref-type="bibr" rid="scirp.97447-ref33">33</xref>] explained similar facts with the limiting factors discussed under the literature review.</p></sec></sec><sec id="s5"><title>5. Conclusions and Recommendation</title><p>Another interesting recommendation is derived from the perspective of system implementation. The logic programming is a type of programming paradigm which is largely based on formal logic. It expresses facts and rules about some problem domains in the business process. Therefore, the handling of arithmetic and logical concepts is the most important consideration when automating ERP application.</p><p>Knowing the whole range of the language syntax helps to construct an error-free programme. It was explained that it is important to use code review correctly. Formatting, spell check and grammar, organising content and flow of content and maintaining templates are advisable.</p><p>To minimise that the basic errors it is necessary to reduce typographical errors for developing abstract syntax trees, syntax errors, indexing, data, disk handling, iterative procedural, initialisation and violated parameters or subscripts and also non-terminating sub-programmes to fix the bugs in the application.</p><p>This researcher has also found such errors in input-output format to get the expected results, main storage allocation to run the application smoothly with enough ram and rom and for store data and retrieval, identified software interface and erroneous “error message” processing for enhancing the user-friendliness, database to store enough data physically or in cloud virtually, reduce the compiler and user interface errors and are highly recommend to produce more efficient and productive error-free code.</p><p>According to the finding of this research also explained the necessity of variables declaration with the variable type and dimensions to represent data correctly. Unique names for variables should be used meaningfully. Standard naming methods for library files are necessary to structure the programme properly and reduce the conflict with system files. In addition to that, the modularization is also important to separate the functionality of a programme into independent, interchangeable modules to make it faster and improve the performance.</p><p>The researcher has explained that coding formatting with the tabs and spaces for indentation enhances the readability of the coding when referring them again for correction or modification. The Programme’s control structure recommends following consistent indentation patterns and limiting blank lines in programs. As a whole, these were also recommended in order to reduce the programme implementation errors.</p><p>Furthermore, the researcher, found that coding syntax has also explained and recommended the use of shift operators instead of multiplication for constructing bit patterns, switch statement, using each variable for exactly one purpose, avoid using global variables within routines, declaring each variable on the smallest scope possible and correcting errors promptly as they occur, and finally keeping code simple was factor which enhances the success of the system. The syntax is language-specific and differs either a little or a lot depending on a language. They are important only in the scope of a particular language. There are some languages that compile to another base language, and they usually have a different syntax. Changing the syntax of a language can be relatively easy or hard, depending on what the syntax should be. Therefore, it is recommended to know the language accurately in order to save time and budget.</p><p>Selecting a proper and programming language is also very important because day by day technology changes, thereby creating new updates as well as plug-ins and supporting objects. It is important, recommended and necessary to keep in touch to decide when to quit the existing application and switch to the new generation.</p></sec><sec id="s6"><title>Conflicts of Interest</title><p>The authors declare no conflicts of interest regarding the publication of this paper.</p></sec><sec id="s7"><title>Cite this paper</title><p>Arachchi, S.M., Chong, S.C. and Kathabi, A. (2019) System Implementation Failures in the ERP Development Process. Journal of Computer and Communications, 7, 112-127. https://doi.org/10.4236/jcc.2019.712011</p></sec></body><back><ref-list><title>References</title><ref id="scirp.97447-ref1"><label>1</label><mixed-citation publication-type="other" xlink:type="simple">Samuel, A.A., Reddy, B.S. and Nair, J. (2014) Conceptualizing Dimensions of Enterprise Resource Planning Systems Success: A Socio Technical Perspective. International Journal of Enterprise Information Systems, 10, 53-75.</mixed-citation></ref><ref id="scirp.97447-ref2"><label>2</label><mixed-citation publication-type="other" xlink:type="simple">Shivkumar, S. and Hasmukhrai, T. (2012) Software Testing Techniques. International Journal of Advanced Research in Computer Science and Software Engineering, 7, 16.</mixed-citation></ref><ref id="scirp.97447-ref3"><label>3</label><mixed-citation publication-type="other" xlink:type="simple">Howden, W. (2006) Reliability of the Path Analysis Testing Strategy. IEEE Transactions on Software Engineering, SE-2, 208-215. https://doi.org/10.1109/TSE.1976.233816</mixed-citation></ref><ref id="scirp.97447-ref4"><label>4</label><mixed-citation publication-type="other" xlink:type="simple">Chaim, M., Maldonado, J. and Jino, M. (2003) A Debugging Strategy Based on Requirements of Testing. Seventh European Conference on Software Maintenance and Reengineering, Benevento, Italy, 28 March 2003, 160-169.</mixed-citation></ref><ref id="scirp.97447-ref5"><label>5</label><mixed-citation publication-type="other" xlink:type="simple">Galin, D. (2004) Software Quality Assurance. Pearson Education Limited, Harlow.</mixed-citation></ref><ref id="scirp.97447-ref6"><label>6</label><mixed-citation publication-type="other" xlink:type="simple">Lewis, W.E. (2005) Software Testing and Continuous Quality Improvement. Auerbeach Publications, New York.</mixed-citation></ref><ref id="scirp.97447-ref7"><label>7</label><mixed-citation publication-type="other" xlink:type="simple">Vinu, V.D. (2006) Principles of Data Structures Using C and C++. New Age International, Telangana, India.</mixed-citation></ref><ref id="scirp.97447-ref8"><label>8</label><mixed-citation publication-type="other" xlink:type="simple">Donald, E.K. (1995) The Art of Computer Programming. Vol. 3, Odd Bookworm, Hackensack, NJ.</mixed-citation></ref><ref id="scirp.97447-ref9"><label>9</label><mixed-citation publication-type="other" xlink:type="simple">Zhang, L., Yuan, S., Tang, J. and Xie, X. (2008) Research on the Composite Arithmetic of Logic Compound Sentences in Decompilation. 2008 International Symposium on Computer Science and Computational Technology, Shanghai, 20-22 December 2008, 442-446.</mixed-citation></ref><ref id="scirp.97447-ref10"><label>10</label><mixed-citation publication-type="other" xlink:type="simple">Widera, M. (2011) Why Testing Matters in Functional Programming. Fern University at in Hagen, Hagen.</mixed-citation></ref><ref id="scirp.97447-ref11"><label>11</label><mixed-citation publication-type="other" xlink:type="simple">Andrei, A. and Daniel, I.V. (2012) Automating Abstract Syntax Tree Construction for. 14th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing, Timisoara, Romania, 26-29 September 2012, 152-159.</mixed-citation></ref><ref id="scirp.97447-ref12"><label>12</label><mixed-citation publication-type="other" xlink:type="simple">Gayle, L.M. (2011) Cracking the Coding Interview: 150 Programming Questions and Solutions. 5th Edition, CareerCup.</mixed-citation></ref><ref id="scirp.97447-ref13"><label>13</label><mixed-citation publication-type="other" xlink:type="simple">Carlton, R. (2017) Three Dangers of a Poorly-Designed ERP User Interface. Converted Media.</mixed-citation></ref><ref id="scirp.97447-ref14"><label>14</label><mixed-citation publication-type="other" xlink:type="simple">Knuth, D.E. (2007) The Art of Computer Programming. Volume 1, 3rd, Edition, Dorling Kindersley, Delhi.</mixed-citation></ref><ref id="scirp.97447-ref15"><label>15</label><mixed-citation publication-type="other" xlink:type="simple">Doverton, D. (2001) Techniques of Document Management: A Review of Text Retrieval and Related Technologies. Journal of Documentation, 57, 192-217.https://doi.org/10.1108/EUM0000000007082</mixed-citation></ref><ref id="scirp.97447-ref16"><label>16</label><mixed-citation publication-type="other" xlink:type="simple">Vangie, B. (2015) variable.html. http://www.webopedia.com/TERM/V/variable.html</mixed-citation></ref><ref id="scirp.97447-ref17"><label>17</label><mixed-citation publication-type="other" xlink:type="simple">Jin, Z.M., Fu, Q., Jin, J. and Tao, J.W. (2013) Characteristics and Module Design of Weaving ERP. 3rd International Conference on Information Management, Innovation Management and Industrial Engineering, Kunming, 26-28 November 2010, 422-425.</mixed-citation></ref><ref id="scirp.97447-ref18"><label>18</label><mixed-citation publication-type="other" xlink:type="simple">Kenneth, E. (2011) Modularization. Aalborg University, Copenhagen.</mixed-citation></ref><ref id="scirp.97447-ref19"><label>19</label><mixed-citation publication-type="other" xlink:type="simple">Georges, E.K. (2009) Building a Service-Oriented ERP from an Open Source Software. Fourth International Conference on Software Engineering Advances, Porto, Portugal, 20-25 September 2009, 33-38.</mixed-citation></ref><ref id="scirp.97447-ref20"><label>20</label><mixed-citation publication-type="other" xlink:type="simple">Leopoulos, V., Kirytopoulos, K. and Voulgaridou, D. (2005) ERP Systems as a Component of the Electronic Supply Chain: Classification of Implementation Risks. International Conference on Computational Intelligence for Modelling, Control and Automation, and International Conference on intelligent Agents, Web Technologies and Internet Commerce, Vienna, Austria, 28-30 November 2005, 676-682.</mixed-citation></ref><ref id="scirp.97447-ref21"><label>21</label><mixed-citation publication-type="other" xlink:type="simple">Song, H., Huiyou, C. and Qing, W. (2009) Component Library-Based ERP Software Development Methodology. 2009 International Conference on Interoperability for Enterprise Software and Applications China, Beijing, 21-22 April 2009, 34-38.</mixed-citation></ref><ref id="scirp.97447-ref22"><label>22</label><mixed-citation publication-type="other" xlink:type="simple">Zhu, Z.Y. and Dai, S.H. (2009) J2EE-Based Enterprise ERP System Design and Implementation. 2009 2nd IEEE International Conference on Computer Science and Information Technology, Beijing, 8-11 August 2009, 509-512.</mixed-citation></ref><ref id="scirp.97447-ref23"><label>23</label><mixed-citation publication-type="other" xlink:type="simple">Chris, P. (2009) Learn to Program. 2nd Edition, Pragmatic Bookshelf.</mixed-citation></ref><ref id="scirp.97447-ref24"><label>24</label><mixed-citation publication-type="other" xlink:type="simple">Andreas, S. (2013) An Empirical Investigation into Programming Language Syntax. ACM Transactions on Computing Education, 13, Article No. 19.https://doi.org/10.1145/2534973</mixed-citation></ref><ref id="scirp.97447-ref25"><label>25</label><mixed-citation publication-type="other" xlink:type="simple">Samantha, M.A, Chong, S.C. and Kennedy, D.G. (2014) A Comparison between Evaluation of Computer Based Testing and Paper Based Testing for Subjects in Computer Programming. International Journal of Software Engineering and Applications, 5, 57-72. https://doi.org/10.5121/ijsea.2014.5105</mixed-citation></ref><ref id="scirp.97447-ref26"><label>26</label><mixed-citation publication-type="other" xlink:type="simple">MITRE (2013) System Design and Development. MITRE Corporation, Bedford, MA.</mixed-citation></ref><ref id="scirp.97447-ref27"><label>27</label><mixed-citation publication-type="other" xlink:type="simple">Creswell, J. (1994) Research Design: Qualitative and Quantitative Approaches. Sage Publications, New York.</mixed-citation></ref><ref id="scirp.97447-ref28"><label>28</label><mixed-citation publication-type="other" xlink:type="simple">George, D. and Mallery, P. (2013) IBM SPSS Statistics 21 Step by Step: A Simple Guide and Reference. 13th Ed, Pearson, Upper Saddle River, NJ.</mixed-citation></ref><ref id="scirp.97447-ref29"><label>29</label><mixed-citation publication-type="other" xlink:type="simple">Central Bank of Sri Lanka (2014) Annual Report 2014.</mixed-citation></ref><ref id="scirp.97447-ref30"><label>30</label><mixed-citation publication-type="other" xlink:type="simple">Sekaran, U. and Bougie, R. (2013) Research Methods for Business A Skill-Building Approach. 6th Edition, Wiley, New York.</mixed-citation></ref><ref id="scirp.97447-ref31"><label>31</label><mixed-citation publication-type="other" xlink:type="simple">Board of Investment (2012) BOI. http://www.investsrilanka.com/</mixed-citation></ref><ref id="scirp.97447-ref32"><label>32</label><mixed-citation publication-type="other" xlink:type="simple">Srinivasan, D.D. and Gopalaswamy, R. (2006) Software Testing: Principles and Practice. Pearson Education, India.</mixed-citation></ref><ref id="scirp.97447-ref33"><label>33</label><mixed-citation publication-type="other" xlink:type="simple">Al-Hossan, A. and Al-Mudimigh, A.S. (2011) Practical Guidelines for Successful ERP Testing. Theoretical and Applied Information Technology, 27, 11-18.</mixed-citation></ref></ref-list></back></article>