As we are now well into our MFD Accounting integration for m3i I thought it was time to discuss how we differ from the usual suspects and how we will be delivering a solution for the 21st Century.

Let me say at the outset that most of this article is my personal perspective and does not apply universally to an entire industry. We can see now, in hindsight, that some very bright people were forced into some difficult decisions in a different technology environment. I concede that I'm making generalisations but I hope that the general flavour of the piece carries the intended meaning: "it's wrong, it's nobody's fault, let's fix it".

Past

Traditional "Copy" Accounting (billing) works thus:

An external hardware device is attached to the port on the copier that provides simple information: paper-size, colour/B&W and a billing pulse is provided as each piece of paper exits the machine. The billing device is able to calculate (simple) costs based on this information and bill per piece of paper. When the balance runs out the device opens a loop which tells the copier to stop copying. Simple.

The problem is that this was simple and worked well in 1990 when copiers were slow, only did copying, fed one sheet of paper at a time and only printed on one side.

Present

In the 21st century things have evolved somewhat in the "copier" world. They are now Multifunctional Devices that Scan, Print, Fax, Email, send to network locations, feed multiple sheets (and scan both sides), then they print on both sides and they do it very fast so often there are three pieces of paper in motion having different processes applied to them at any one time. Oh, and they do a bit of copying if you ask them to . In essence copiers do not exist anymore and they have been replaced by these highly complex MFDs.

Hindsight 

The problem for Copy Accounting solutions providers is a historical one. Their equipment was on an evolutional path that was fine for the copier but is fundamentally challenged on the MFD for anything other than copying. I should clarify that there are distinctions to be made here. The design of the server-side element of the accounting system has been driven by the way the front end hardware works; this is short-sighted in hindsight but you can see why. Remember also that some accounting server solution providers do not make their own hardware and have no opportunity to alter it.

The main problem lies with the design of the hardware devices which was in turn dictated by the information provided by the copiers themselves which has traditionally been poor.

So essentially the situation is this: 

1. Copier manufacturers woke up late to the fact that a Copy Accounting industry would even exist.
2. By the time they did and started providing external copy information the Copy Accounting guys were already hacking it to work and had established an interface.
3. The hardware didn't really evolve from there (other than adding colour and moving to a binary system), we have the same stuff even now although they have evolved some clever workarounds to achieve what they need.
4. Print Accounting server solutions looked to implement Copy Accounting, saw the available hardware and decided to use it.
5. They designed their server software solutions to mimic the methodology employed in hardware (a generalisation, I concede). 

Change? 

Rather than reinvent the genre they decided (almost universally) to patch it up. Some vendors are able to bill in a semi-sophisticated way having applied a series of workarounds over the years but none of them really work or the user must accept compromise.

A good example for copying is the method still employed: they discover that they are about to run out of money as the last piece of paper that the user can afford triggers their costing logic. At this point is impossible to gracefully prevent the two that are following it at high speed from being completed - cost overrun.

Another problem is a lack of transparency: it's difficult for the user to know how much it will cost until they try to do it and find out they couldn't.

This says nothing of the lack of any reasonable way to cost scan to email or faxing. Email for example, the bandwidth required to email any given scan varies enormously because of compression and original size; a B&W A4 scan with some text on it is quite small while an A3 Colour image scan is enormous - we are talking orders of magnitude. How can you convey this to the user after the fact or how can you derive an average costing mechanism?

I could go on, but basically its yesterday's solutions for yesterdays machines with a few patches. Customer demand drives change and innovation, without it there is no motive for change. Fortunately we see signs that this is beginning to happen. Users seem to be less willing to accept the restrictions and compromises. Perhaps the entire industry offering has not matched user expectations for some time but if there is no differentiation there is no choice.

But surely, I hear you say, "the new breed of embedded solutions will have fixed all this?". Well, that remains to be seen but UI restrictions on the MFD, and a need to get quickly to market indicate that mostly you are seeing the same solution, but in software, and sometimes at the same price! Its a matter of perspective i suppose.

Future (not distant I hasten to add) 

Enter the m3i concept. This is not fundamentally about billing, it's about exposing a machine's functionality in such a way that radically different User Interface experiences can be created for users with varying requirements as a lot of this site will tell you. Obviously we always knew that m3i's extensibility means accounting would be a logical extension of m3i and are now working to incorporate it.

Because we expose extremely granular information about the MFD and what its processes are doing it is relatively simple to build an accounting client that uses this information and feeds back its own supplementary information for multiple User Interfaces to simultaneously expose (cost/balance/etc.). While this makes us far superior, it is not really the differentiator.

Because of our unique position of control within the MDF (not an external device) we are able to shift the way this works at an operational level. Our UI metaphor is to get an image from somewhere (usually the scanner) and send it to somewhere else (print/email/folder/fax/etc).

So we work thus:

1. User inserts some originals and sets up his job.
2. User then initiates the job at which point the originals are scanned and then the job held.
3. User is then presented with their balance and a cost for the WHOLE job. Importantly this can be calculated in a fair way because we have all the information after we have scanned the originals - Email can be based upon transfer cost per megabyte; Fax can be costed on pages transmitted or again based upon page complexity; Scan to Print can be based upon any metric you choose: scan impressions, colour, number of copies, duplex, etc. You don't need to have a poster on the wall explaining a pricing structure as this will be presented in a simple choice: "This is how much all of what you want to do will cost, you can afford it, do you want to proceed or change what you want?"
4. The user indicates his desire to complete, change or cancel and the job continues to fruition in the background. 

In summary we are different for the following reasons: 

• Fundamental changes in the way the user interacts with the MFD and the billing system
• Fundamental changes in the way costs are calculated, presented and accepted by the user
• Fundamental changes in the way billing solutions can be delivered - the billing system can be hosted software as a service on the Net
• Expanding the solutions delivered (and paid for) on the MFD - printing documents/photos from the web, scanning to web storage, etc.
• Security - we use SSL and other methods to protect the system, you may be surprised who doesn't...
• Our solution can bill for any abstract functionality on any machine type that we enhance with an m3i Machine Interface (not just MFDs) or can make costing decisions that involve multiple machines in a linked process
• Concurrency: there are multiple part-finished jobs belonging to different users simultaneously occurring on an MFD, you need to keep track of all this, it’s not a linear process.
• We don't approach billing from a server or a billing device perspective. We approach it as we always do, from a User Interface perspective. We seek to integrate it, make it a seamless part of the process not a thing in its own right and we don't dictate the way in which it is delivered to the user.
• Additionally you have all the other advantages that m3i can offer. Accessible billing devices, who ever heard of that? Oh and of course, you can talk to it about the job and its costs and it talks to u back - magic 

Glad I got that off my chest, now we can hopefully get on with making things better!