You might also be interested in
Replies (6)
Please login or register to join the discussion.
Why does anyone purchase ......
a system that does not allow paper based reports to be exported in some form (i.e. Excel, csv etc)
The thrust of the article seems to be about stripping data out of existing reports; however this would surely not be necessary if exports existed
From memory there was a product Monarch?? in existance over 10 years ago that provided just this functionality - i.e. create a template & fire the report through the system; resulting in an export file of some type
About the author...
Thanks for your comment, JC. I should probably clarify matters by pointing out that Olly Bond is product manager for Datawatch, which developed the Monarch system. This piece is based on a company whitepaper posted on AccountingWEB. I found the explanations of the report types quite helpful.
The paper has a lot more detail about how Monarch actually works, if you want to find out more about it.
My apologies for omitting to add a clear identification at the end of the piece. This will be rectified very shortly.
John Stokdyk
Technology editor
AccountingWEB.co.uk
Database knowledge is the key element
To my mind the extraction of B.I. data from reports is prone to the same problems and limitations as those that apply to SQL Queries and Data Warehouses. In that a fundimental understanding of data structures, their relationships and limitations is essential before B.I. data can be extracted and used with any confidence.
Unless an end user has such knowledge, or can easily communicate with someone who has that knowledge, the type of vehicle used to extract the B.I. data becomes subordinate to this key element. So the placement of IT staff into end user departments is the critical step that many organisations miss for whatever reason.
Also, to be useful B.I. data must be timely. Getting the required data after a deadline has passed is of little or no benefit. That is why I believe that the ability to construct SQL Queries directly in the operational ERP system is vitual.
As it greatly reduces the I.T. delay in constructing Data Warehouses/external databases.
Once a SQL Query has been constructed it can be incorporated into a B.I. Score Card for running as many times as required (system performance permitting). Allowing managers near instant access to B.I. data. In this way fluctuations/deviations can be quickly spotted and appropriate management actions taken.
Such an implementation may not be suitable for very large international organisations (due mainly to the volume of data), but can work remarkably well for the vast majority of small/medium sized organisations.
Regards Robert Brook
Director of Rowanberry Consultancy Ltd.
Seller of Acceptum Business Software.
Appologies missed the reference to Monarch ....
but Alastair is quite right about his mainframe comments - good product in its day
The only possible exception is where auditors need to extract data in special circumstances
He is also perfectly correct about users (not)knowing what they want - otherwise it is cystal ball gazing
its in the title!
there is a cost of getting information out of a system or systems, and often part of that cost is getting the base system to capture the required data.
data in a production system is geared to the needs of that system/business process - it would be strange if it was not. and the design of that rarely (never) takes account of information needs from a BI system.
this type of requirement can never be met from a commodity application - many have tried (and failed). It has to capture data from disparate systems, and often it needs interpretation before it gets near a user, and of course identifying generic requirements is difficult/impossible.
That is all implicit in this piece, simply because it talks about technical solutions rather than business solutions; but the main problem (that this masks) is that end users actually don't know what they want, and even if they do then those wants change over time - and they are driven by the dynamics of the business and its market place(s). By the time you have built what you want today, it is out of date!
This becomes more obvious when you try and implement this stuff - it is like a new years resolution, lots of enthusiasm over christmas, but by january 5th it is gathering cobwebs!
In fact the highlight of this item is in the title, and it is the word simpler. Work out in simple terms what you want, and perhaps you might both get it and use it, but accept that you are likely to have to rap with a techie. And if you don't believe me then read the latest installment of the CEOs diary.
ps
I use Monarch - it's a great way of getting data out of mainframe reports, but it has had its day. Our mainframe is on its way out, and it is easier to specify reports and data extracts and get them to users from the modern network system that is supplanting the mainframe. Monarch is becoming redundant.