Banta Global Turnkey

5.1.2 Technical Dimension

The technical implementation of BGT’s system was complex as they had so many different systems to integrate. As discussed previously, security was paramount and the use of a web server meant that BGT were able to limit the amount of data available to a hacker, should the system ever be breached. Additionally, a firewall positioned between the web server and other internal BGT systems greatly reduced the risk presented by hackers.



When a user makes a request, that request is routed through the web server to the application server where a decision is made on what to do with it. To generate the screens and the required information to fulfil the request, data is taken from the iView data-warehouse. The iView data-warehouse contains a sub-set of the enterprise applications database which is propagated with data from all of BGT’s systems. No direct link is ever made into the enterprise applications database for reasons of security and performance (the ERP database contains _ a terabyte – or 500 gigabytes! - of data).

In order to build an industry standard system that was fully future proofed, BGT spent a lot of time considering the tools the team could use. The decision was made to design the web application using J2EE and JSP, open source industry standard environments and the most widely accepted development standard for web based applications. Elements of XML were also included in the system allowing users to export data in this new industry standard format for data transfer between systems (see earlier box-out). BGT built its data-warehouse using Microsoft SQL, the accepted industry standard for high-end, enterprise level database construction.

One of the most important parts of the system for BGT was the replication of data. The team needed to be sure that they used a technology that could pull data from a number of different sources (ERP Systems - JD Edwards and Acuman – and Shop Floor Control and Quality Control systems) before exporting it to the iView data-warehouse – in all, five different systems were farmed for information. Data Mirror was selected as the bestin- class application for providing this functionality

5.2 The Project Team

5.2.1 Internal Team

As with most large organisations running projects of this scale, there was a large and well structured project team, led by a project manager:

• Simon McGrath, Project Manager/Designer – Simon had responsibility for system design, requirements specification, development resources, research, ensuring process integrity and managing the team of internal developers.
• Noel Dillane, Vice-President of IS – Noel was on the project steering committee and was the main driver from an IT perspective. Additionally, he had overall responsibility for getting the project implemented on time and within budget.
• Sandy Whyte, Head of Business Team - Sandy’s team of 10 identified the specific requirements of customers and suppliers and acted as the liaison between those customers and engineering. Sandy was also responsible for customer and supplier training.
• Edwin Van Mierlo, Head of Technical Services – Edwin’s primary responsibility was the system infrastructure and ensuring the correct hardware, software and licence agreements were in place.

5.2.2 External Team

BGT’s close working relationships with its ERP vendors, JD Edwards and Mentec (Acuman) meant that it was able to use the resources of those organisations on a consultative basis. BGT had been running both these ERP systems for some time and, as a result, had strong relationships with both organisations.

It order to ensure that iView was able to integrate seamlessly with both JD Edwards and Acuman, input from their consultants was vital – the last thing BGT wanted to do was crash its ERP systems when iView was first installed.

5.3 Third Party Selection

Like many SMEs, the team in BGT didn’t have the appropriate level of eCommerce experience. However, the technical background of the team meant that they did have a rough idea of what they needed to implement the system.

Following a review of vendors in both the B2B and B2C spaces, Limerick-based consultancy Piercom (www.piercom.ie) was selected to undertake the research and development phase of the project. Piercom had worked previously with both JD Edwards and Mentec and had expertise in developing similar systems for other organisations.

Following successful completion of the R&D phase, some of the development was also outsourced to Piercom. One of the key factors in Piercom’s favour was that they responded to BGT’s request with something close to what the team was looking for. “Unlike other vendors, they didn’t try pushing something onto us that we didn’t want”, said Simon McGrath.

Reference checks were undertaken prior to signing contracts and non-disclosure agreements with Piercom to ensure that they had done what they said they had done. At that time licensing agreements were also signed – BGT wanted to be absolutely sure that they would retain ownership of intellectual property rights for the system source code.

5.4 Setbacks and difficulties

Given the scale of the project, the number of issues were quite low and were mainly in the area of integration and data transfer.

The BGT team found that when iView interrogated the data warehouse the system slowed considerably. Given the integrity of the data warehouse, this performance hit was tolerable but was still considered unacceptable by the project team. In order to solve this, BGT worked with a 3rd party organisation to find a solution that would reduce the performance hit to a reasonable level. Additionally, there were a few small problems when bringing suppliers on line – the biggest of these being browser compatibility. BGT couldn’t dictate which browser was used to access iView and thus had to make the system available to as many platforms as possible. None of these issues had a major impact on the timeline and project plan.

5.5 Rolling out the system to customers

When iView was originally commissioned, it was designed around one specific project that had 6 organisations with 12 users using 7-10 reports.

As the system was rolled out to the users, the business team tested the two processes in parallel (for a few weeks). Reports were generated as normal using the manual method and the business team ran the reports using iView. If there was any discrepancy at all, the issue was passed back to the development team for investigation. This ensured performance of the system prior to roll-out. “We had a zero-tolerance approach to quality”, said Simon McGrath, “if there was a discrepancy we had to understand why – we had to present 100% accurate information”.

Each organisation was visited by a member of the Business Team (headed by Sandy Whyte) who provided training to each of the users within that organisation. This was also an opportunity to sell the system to users. According to Simon McGrath “It wasn’t a hard sell due to the extra functionality that was going to be available to users”. Initial feedback from customers and suppliers was very positive.

Given that the BGT team had put so much effort into the back-end it was fairly easy to add on new reports and new users from there. At time of writing this case, the system had 700 users in 75 organisations using 50 reports.

5.6 Budget

The problem with measuring this project is that development of the system is ongoing and there is no end-point as such. Based on the original application document, the project met and only marginally exceeded the budget as outlined.