After posting my previous blog, I realised that I hadn't updated my readers why the tags for it were DBA (Doctorate of Business Administration) and ERP (Enterprise Resource Planning). I wrote about a year ago about working towards a doctorate, where my subject was to be areas in which the classical model of ERP fails. But after a few months of cogitation, I concluded that I was able to find solutions for these areas of ERP failure, and so I needed to find a new subject.
This wasn't too hard as I shortly came across an article entitled Attack of the killer spreadsheet which was very much aligned with my own thinking. To quote some of the article,
The really important thing to remember about spreadsheets is they are not the companies ERP system. The company ERP/MRP system must always remain the backbone, the main data repository, the source for management information and where business transactions and processes are recorded and tracked.
But what’s wrong with spreadsheets – I hear you ask? Well, the way most spreadsheets are configured means that they miss fundamental (and critically important) ingredients that most ERP’s are equipped with out of the box!
Improper use of spreadsheets often stems from a perceived lack of functionality within the ERP system or a work around where the ERP logic isn’t aligned to way the company wants to operate. Often the easiest, or the perceived easiest, method of fixing that is to “plug” a spreadsheet in to solve the problem. We’ve all seen these out in the field and their function can vary from a simple list (my ERP doesn’t record all the data I need) to acting as an EDI interface between a customer and supplier ERP system.
But what’s wrong with spreadsheets – I hear you ask? Well, the way most spreadsheets are configured means that they miss fundamental (and critically important) ingredients that most ERP’s are equipped with out of the box!
Improper use of spreadsheets often stems from a perceived lack of functionality within the ERP system or a work around where the ERP logic isn’t aligned to way the company wants to operate. Often the easiest, or the perceived easiest, method of fixing that is to “plug” a spreadsheet in to solve the problem. We’ve all seen these out in the field and their function can vary from a simple list (my ERP doesn’t record all the data I need) to acting as an EDI interface between a customer and supplier ERP system.
On this basis, I put together a doctoral proposal, part of which currently reads as follows:
ERP programs are packaged with reporting systems of various level of complexity and capability; these systems are normally based on SQL (Structured Query Language), a database computer language designed for managing data in relational database management systems. The use of SQL is normally the province of IT professionals who configure and support the ERP programs; the end user is dependent upon the professionals and rarely has the ability to create reports of her own within the system.
In order to circumvent this inability – and for other reasons – the use of Microsoft Excel is prevalent within organisations using ERP. The use of Excel can both help and hinder the effectiveness of ERP systems: "when employees use spreadsheets, they create the very problems that ERP systems are meant to address: silos of data, inconsistent information, manual tracking of information and broken business processes".
I propose to investigate the use of Excel in organisations using ERP in an attempt to determine whether Excel does indeed help or hinder; it may well be that certain functionality helps whereas other functionalities hinder.
I propose to ascertain this by conducting interviews with users of ERP/Excel. The majority of the interviews will be conducted with users of the Israeli developed Priority ERP system, as I am most familiar with this product. I intend, however, to conduct interviews with users of ERP systems such as SAP, Baan and Kav (another Israeli product). I also intend to conduct interviews with Priority users in Britain and possibly other countries. These interviews will enable me to determine whether the efficacy of Excel depends on the user's level of sophistication (and knowledge of her ERP system), on the ERP program or on the national culture.
In order to circumvent this inability – and for other reasons – the use of Microsoft Excel is prevalent within organisations using ERP. The use of Excel can both help and hinder the effectiveness of ERP systems: "when employees use spreadsheets, they create the very problems that ERP systems are meant to address: silos of data, inconsistent information, manual tracking of information and broken business processes".
I propose to investigate the use of Excel in organisations using ERP in an attempt to determine whether Excel does indeed help or hinder; it may well be that certain functionality helps whereas other functionalities hinder.
I propose to ascertain this by conducting interviews with users of ERP/Excel. The majority of the interviews will be conducted with users of the Israeli developed Priority ERP system, as I am most familiar with this product. I intend, however, to conduct interviews with users of ERP systems such as SAP, Baan and Kav (another Israeli product). I also intend to conduct interviews with Priority users in Britain and possibly other countries. These interviews will enable me to determine whether the efficacy of Excel depends on the user's level of sophistication (and knowledge of her ERP system), on the ERP program or on the national culture.
So, whenever there's a blog entry about someone intending to do something in Excel and me suggesting that they do that something in Priority, know that this is connected with my (proposed) doctorate, hence the DBA tag.
Although I have applied to the DBA programme at Heriot Watt University, I have yet to be accepted, as the accepting committee will only discuss my application after I complete my MBA degree.
No comments:
Post a Comment