Why Integrate?
What is the advantage of an integrated over a discreet application?
Take, for example a discreet application that most chains have, DSD. This is for the most part an application that allows the store receiver to scan in product at the back door, generate a pile of paper with notes on recording price discrepancies and then create an unenviable administration task in A/P. The job of stocking the shelves in the stores is placed on the shoulders of the vendor, pretty much with no input from the store. So guess what ends up on the shelves? Stuff that the store wants or stuff that the vendor has to offload?
Now how about opening up the application to POS movement, so now we know the rate of sale of every SKU in the store or across all stores? How about recording movement so you can see the trend over the last few weeks, the same time last year and use promotional history to determine the effect of TPRs on product demand? Why not share that data with the vendors, so that they, in turn, can buy in and supply you with product that will turn over faster?
Having impacted the sales opportunity by optimizing the product mix in the store, what are we doing about administration costs? The answer: host the application on a central server and use technology to make receiving paperless! Eliminating scraps of paper means not losing those scraps of paper and taking the confusion out of the picture! Apply this principle to Accounting, Payroll, Buying, and Switching services. Back everything up with a CORE data warehouse application and you have a truly efficient, accurate, and timely vehicle to run your business.
With such an approach, the question to ask is: how can current technology and advanced design bring new value to a solution, rather than simply generate a tedious overhead.
Why have a relational database?
Now let’s take the issue of database in this. Pretty much all software vendors use a relational database to manage the data used within their discreet application, because it is easier to manage data that way. But such horizons are limited to the application area that they are addressing. In the above example of DSD, you might think that using POS movement and inventory levels to predict requirements is thinking outside of the box, simply because that data we are talking about originally comes out of the POS.
In Midax, we just think of this as basic lateral thinking. It is simply breaking a bad habit by applying common sense to the design of the database that should support a given decision process. The next step in that is to use our system intelligence to know where to go to get that data and how we need to store it. And once you have done that, the DSD component needs to be designed with in-built expert rules and drill-down data enquiry capability that accesses all that data.
How do I reduce data file maintenance?
There are very few software vendors in this industry, who take the view that all the chain’s data for all applications should be on one relational database, which underpins all operations. Our system modules in these pages are all described for the specific application.
However, all these applications are grounded in the same Midax Relational Database Platform. The same product file that is used in Midax DSD is also used in Midax Price Hosting as well as in Midax Frequent Shopper. Change a field in one application and you change it for all routines that use this data. Likewise the same customer file we have in Midax Check Authorization is the same we have in the Midax Frequent Shopper Data Warehouse. Why? Because enter-once-use-many-times data entry reduces admin costs and is better for data integrity than any semi-automated system, where one data entry is then bundled into ensuing file updates for end-of-some-timeframe updates that will hopefully work.
Now take that concept of a fully integrated relational database that underpins all Midax applications and compare it to our operative zigzagging through multiple software vendor minefields. Within Midax, at one stroke, you have eliminated import and export routines. The maintenance has gone away!
What has happened to all my data?
Having eliminated conventional data maintenance issues, bear also this in mind. In Midax, data is not stored in rolled up month to date, year to date buckets, where the detail is lost forever. Instead, data is stored in its original format; free to maintain its relationship with all other data in the original form the data was received or processed.
Why is that important? On a day-by-day basis, you eliminate the admin inside and outside the MIS department painting data white and then black again. Not all data comes in on time. Not all of it is accurate. So having the ability of going back in after the event and making the corrections makes your company reporting accurate. Redefining certain data properties and then running different report views on movement means you can open up your analysis options into what-if interrogation of your data. Just think - no more band-aid solutions to reporting and reporting. Imagine, being able to believe the figures you see!
Next, when one day, when you need to go back and find out what really happened, you will be grateful that all your original data is intact. The devil, as we all know, is in the detail. Like one Midax customer who used the database to recreate scanning reports for billbacks of over a year old, which hadn’t been raised through a combination of clerical error and inaccurate vendor-supplied data. Or take another customer, who used sales movement analysis to discover that the policy of marking down meat at a given time of day had actually created a market of marked-down meat. Tossing the product made a better contribution to bottom line. When you know what you want to look for, what is the value of it still being there for you to find? Not all business decisions can be made on the back of a cigarette packet. Some benefit from factual research.
How do I link Midax into my other systems?
Decide that any application extension or any new application will draw its data from that integrated relational database and report back to that database the transactional detail of all discreet actions in that discreet application and what have you done? You have maintained your command and control strategy and reduced interface maintenance to a one to one relationship, not, as our soldier above with his multifarious software vendors has it, many to many.
This does not eliminate software release update issues, but it will provide you with a map through the minefield and it takes most of the mines out of the minefield.
Compare this approach to that of most of our competitors, or systems integrators bundling packages from a variety of software vendors, with use and toss txt files, relying on import and export routines that sort of work on a good day. Do you really want to run a multi-million dollar business in this way, with HVRs breathing down your necks?
