I’ve often talked about Monarch’s ease of use advantage, in that it doesn’t require you to have a programming or technical IT background to get the results and the data that you need.
But what if you do have the skills of a programmer? You wouldn’t possibly need Monarch then, would you? You’d easily be able to quickly extract, filter, and summarize any data from any system, right? You’d have no need for Monarch.
Not so fast.
Even if you do have the ability, that sort of work can be a very complex, time consuming and even expensive task.
Monarch Simplifies the Complicated
I’m reminded of one particular occasion that really proved that Monarch is a great tool for everyone that works with data.
Our Finance Director had been requesting that our IT department supply him with a special extract from our ERP system; something that wasn’t available in any existing report. He’d been waiting for weeks for useable data for his analysis. It turns out that IT had extracted hundreds of thousands of rows, and he’d been asking them to summarize it for him somewhat as he wanted to conduct his overview analysis with Excel, and he just couldn’t handle that much data.
The IT group kept putting him off, saying that they just didn’t have the time to write the complex query he needed to accommodate analysis in Excel. Have you ever heard that one?
In the end he came to me with his story, and his mountain of data. It took all of about five minutes to give him what he needed, using Monarch of course.
Even IT Needs Good Tools
Monarch can be a useful addition to the IT department’s tool kit. Because of its ease of use, the IT group can absolutely take advantage of Monarch.
One way in which IT could take advantage of Monarch would be in the system conversion process. There’s often a raft of data to bring into the new system from the old system, and Monarch’s clear interface can assist in that process enormously, easing the task of bringing expedited and accurate results to the new system.
How do you use Monarch (or Monarch’s big brother Data Pump) in your IT department? What does it do better than other available tools? Are there tasks that you couldn’t imagine doing without it?
Monarch: The Conflict Resolution Tool
Historically, Operations groups and IT groups have often agreed to disagree. Both groups can share some common ground when they excel with Monarch.
{ 1 comment… read it below or add one }
Conflict of interest or tool of convenience?
If, like me, you have at some stage performed an IT role acting as in intermediary between the business user and the programmer you probably realise that more often than not there is a communication ‘gap’ of some sort.
It could be terminology or it could be assumptions about ‘what people know and understand.’ Or maybe a question of familiarity.
The non-technical end user knows their data (or we must assume they do if they have been assigned to talk to the IT people about requirements. Of course, this is not always true …). They will assume that the IT people they are talking to understand their data in just the way that they do themselves.
I would suggest that this is rarely the case.
The IT people will see the problem in an IT light without really having the faintest idea of how the business runs and uses the data fields. If a field has a name and an intended use that is what they expect it to be used for. That the users, since time immemorial, have used it for something else of that it is merely a repository for some information from an an earlier redundant system will, more often than not, be unknow to them.
So things are discussed, questions half form, half presented and half answered and, perhaps six months later, a new report is proudly delivered to a client who has no idea what it is telling him but feels that it is unlikely to be what he thought he was asking for.
The output is never used. 90% of all saftware code ir, apparently, never used, especially reports. (They may be run once to see if they work …)
The 6 month development cycle probably suffers from ‘things moving on’. Heck, in that time I have know of companied being bought and sold several times over with a ‘corporate integration’ in each ownership cycle!
Now, with Monarch as a pro-typing tool IT has the possibility to satisfy immediate demand very early in the request cycle but yet retain control and iteratively develop a pro-forma or prototype solution for their client before deciding whether to move to an integrated coded solution (and all that goes with it including revenue transfer) at a future point.
Protyping can relieve the immediate client/delivery conflict AND ensure that the final coding project, if it comes about, has a complete and working specification (the Monarch solution) against which the coding and testing should be able to delivery very rapidly indeed.
If not, why code at all?
Grant