Home » Ch 6 – integrating information systems

Category Archives: Ch 6 – integrating information systems

Mini-series Part 3: Digitalization and the accountant

In the first two parts of this mini-series, I discussed the definitions of (Part 1) and role of AIS (Part 2) in digitization and digitalization. In this third part, I would like to highlight the development of the role of the accountant in this regard. Digitalization is both boon and bane of the future accountant – on one hand, it helps further the minimizing of his/her involvement in the nitty-gritty daily grind, the “bean-counting” the end of which has long been heralded by the automation of accounting processes. On the other hand, though, it raises questions about the legitimacy of the role – in other words, are accountants still needed? It seems an inevitable development that more digitalization means less and less accountants are needed to perform the same tasks, both in scope and quality. In this highly interesting article published by the WHU in Vallendar/Germany, the authors highlight eight challenges that current and future (management) accountants might face when confronted with the digitalization trend. The video below helps as an executive summary of the article, but I highly recommend to have a good read – you will learn that the digitalization trend does not have to automatically mean the end of the (management) accountant – if they get proactive with the technology and concepts involved.

Advertisement

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.

Big data problems

It’s bollocks, quotes an interesting article from The Economist – see this link

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.

 

 

 

 

Keeping data secure

Image from wikipedia

Image from wikipedia

It is good practice to keep a backup copy of key business data. Basis practice is to take a backup of key organisational data regularly on a medium that can be stored offsite if necessary. Arguably, in a cloud computer environment a backup is not needed, but many organisations still (and probably always will) maintain some data internally.

One quite old method of storing a backup copy of data – or even storing data – is on magnetic tape. As recently noted in the Economistthis backup medium has gained a new lease of life. Cloud storage has become so cheap and fast, that the tape could have been seen as redundant. But one thing a magnetic tape has is portability – it can thus be easily secured anywhere, away from normal business risks or even hackers. As noted in the Economist article, many organisations also now generate huge volumes of data (i.e. big data) which may be useful for analysis. Tapes can easily store such data.

The article also notes four advantages tapes have as a backup medium:

1- data can be retrieved fast

2- power is not needed to store the data

3- there are secure as mentioned

4-  they can be repaired (spliced).

There are also likely to be improvements in tape technology in coming years as their value for storing large amounts of data has come back into vogue.