Home » Ch 5 – Enterprise systems
Category Archives: Ch 5 – Enterprise systems
The pros and cons of ERP systems in the cloud
Enterprise Resource Plannin
g (ERP) systems like SAP, Oracle, or JD Edwards have been influencing business processes for the last three decades. At one point, however, the market was overly saturated, as corporate-wide systems like ERP were only affordable for large companies. For small and medium enterprises, ERP systems were unaffordable, and the value added (i.e. costs saved) through their use debatable.
With cloud technology in the mix now, ERP systems have moved to the cloud. SAP S/4 HANA, for instance, is an offering that runs on the cloud, seemingly providing the most powerful type of information system to businesses large and small. With all technological advances, though, the grass is not always greener. In his blog post about the pros and cons of cloud ERP, Forrest Burnson gives a comprehensive overview what factors should enter the decision-process when a company starts considering adopting cloud ERP systems.
Old-school data security – the floppy disk is alive and kicking
Accountants have an inherent interest in corporate data, and as such, its security and privacy. In our book, we write about the newest technologies, including cloud computing, where we claim that the cloud can provide a measure of security to companies that the companies themselves would be unable to garner. However, not always is the newest technology the only way to go – in this article on BBC Tech, the author explains how the good old floppy disk, in spite of swan songs having been sung for decades by now, is still alive and kicking. Why is that? Why do organisations like the Pentagon or manufacturing companies keep using this seemingly outdated format? In short, the floppy disk has proven age-resistant, nigh impossible to hack (unless it is lost and found by unauthorised third parties), and usually found in systems that are very cumbersome and costly to update.
So it is one thing to appreciate the newest of technologies, but one should never forget or discard the old ones! As accountants, we should not forget that – for some businesses, it might be better to stick with the old.
The technological crux of the British police
For the well-connected criminal in Britain, these seem beneficial times. Whilst crime organises itself using the Dark Web and social media, leveraging whatever new technologies may offer them, police forces lag behind considerably. Where the need for integrated data and data sharing is somewhat undisputed in the business context, it seems less obvious when it comes to the institutions that are supposed to preserve the fabric and foundations of society. The most prominent example is the British police force that seem a far cry from the technological depictions of the likes of TV’s CSI. According to this article in The Economist (“Low Tech Coppers”), the mish-mash of the police’s IT landscape seems to be an obstacle rather than a means to solving and preventing crime. The article cleary illustrates the need for an integrated view on big data in the societal context – with a staggering 750 different computer systems that do not share data with one another, one cannot help thinking that this should be an obvious choice for investment in adequate IT.
Inbound interfaces – an example from SAP
As you might imagine, any business that starts using a system like SAP will most likely want to transfer data from their old system. This might be anything from customer details, to open invoices on customer/supplier accounts, to closing ledger balances. Transferring can be done two ways, manually to using an interface.
Ultimately, using an interface is probably best as it automates mundane work and is likely to be less error prone than manual entry. For example, can you imagine and organisation with 2,000 customers, each with 5 outstanding invoices? That’s 10,000 entries to be made manually – not an ideal scenario. So an interface would be the best option, but what is an interface?
In this case, we can describe an interface as an agreed format to transfer data from one system to another. SAP for example uses a concept call iDocs to not only transfer data within SAP, but also receive data from outside. You can think of an iDoc as a simple text file, with lines of text. The first line is a control record, with each line thereafter a data record. In simple terms, the control record tells the system where the data which follows is to go. Each record (line) in the iDoc is 1,000 characters long, and the position of each character determines what the data means – the positions are defined by SAP. Here is an example of what an iDoc record might look like:
ORDERHEADER 1088 1089 12500.50 24121998 Micky Mouse
Normally, a programmer develops some programme code which can extract data from the sending system to comply with iDoc format. Then, when the programme is run, the iDoc is read by SAP and the relevant data fields are populated e.g. customer details, open invoices.
Business information systems for accounting students 