fun things to do with BizTalk – #1

#1. streamline the processing of paper forms you can't totally eradicate yet

The paperless office. Remember that? We're still working on it. And sometimes there are paper forms that you can't get rid of just yet. For a variety of reasons. Some legal. Some practical.

One example I've seen is a large manufacturing company who gets 70,000 Proof Of Delivery forms each month. Traditionally they would receive them, then someone would make a note that it had been received, and they would be archived in boxes somewhere offsite in storage. Which is all fine until a customer disputes an invoice and says they didn't receive the goods sometime in the future and then you have to retrieve the POD. If you can. Sometimes they get lost. Usually they take several weeks to retrieve. Which mean you have outstanding receivables.

A solution:

When the PODs come in, run them through a high-speed scanner. OCR the data. Pass the data and the jpeg of the document to BizTalk. It can update a field in your ERP to note the receipt of the POD against the original order. It can also place the jpeg into a SQL database for future retrieval via an intranet portal in case of dispute.

The benefits? Less chance of losing the PODs after they come in. Faster retrieval of the POD in cases of dispute, which means faster turn around of outstanding accounts receivables. Using BizTalk to update your ERP means less human data entry, which lowers ongoing operating costs and lowers error rates, providing better data integrity. I've seen solutions like this literally save companies millions each year. The cost to deploy it should be well under $250K.  

Comments (17)
  1. Jack Mayhoff [MSFT] says:

    Yeah its those damn TPS reports with the new cover sheet.

  2. Ziad says:

    From experience, a couple of things you’re missing in the process:

    – how to correctly identify the field to update in the ERP.OCR is not enough for that: you need something like IDR, or barcode, (or worse: human input): for that you may need to redesign the POD document. ($)

    – Not all documents are going to be accepted, so you still need humans to correct recognition errors: that usually means buying better screens (otherwise you can’t see a full page + the rest of the application properly) ($)

    – typically, such solutions means a huge increase in storage space (you would be storing tifs, instead of jpegs). You’d want a more solid repository than SQL server, something that you can couple with a jukebox server ($$)

    – You have to update your ERP to go grap the image from where it is stored as well

    – network traffic also goes way up, during capture & retrieval so you’ll want an image compression technique, but also typically upgrade your network capability ($$$)

    – your electronic documents won’t stand a chance in court, unless you take aditionnal measures (non alterability, biometrics, … $$$$)

    – you still need to do something with the paper documents: file them, stamp them, etc…

    All in all, initial investment can be a lot more thant 250k when you factor that in…

  3. Jack Mayhoff [MSFT] says:

    You forgot retooling and retraining´and then maintenence, licneces , and adminstering

  4. Jack Mayhoff [MSFT] says:

    And time spell checking 😐

  5. Cameron Reilly says:

    Ziad, all good points but we’ve been able to work around them:

    1. Barcodes are normally what we use, you’re right, and we have re-designed the POD to add them. No big deal. Might require a new thermal printer to produce them. Small $.

    2. With a barcode, why won’t all documents be accepted? If it comes back with a signiature, its a POD. However, we normally do build an exception routine into Biztalk to alert someone if a form doesn’t make it into the ERP.

    3. We haven’t found the storage to be onerous. Once upon a time that might have been the case, but not any longer. We don’t store them as tiffs, just jpegs.

    4. BizTalk can update the ERP with a link to the location of the stored image if need be, but its just easier to use Sharepoint to search and retrieve.

    5. The impact on network activity can be limited, especially if you are only producing jpegs, but bandwidth usually isnt an issue these days.

    6. You’re right about the electronic documents not holding up in court, that’s why we still keep the paper version, but hope we don’t need to resort to it.

    7. ditto.

    I’m sure these issues are still relevant in some situations, but, as I said, we’ve found they aren’t a major hurdle most of the time!

  6. Sam says:

    What a waste of Biztalk. Theres nothing here that requires biztalk. You’d be better off (Cheaper and easier) to create a simple application to do the same thing…

  7. Sam – yeah I often hear comments like that when discussing BizTalk, especially from developers. However, many of my clients seem to be moving away from developing applications from scratch. Instead they are moving towards a model of configuration rather than development. Buy versus Build. The value proposition is even more powerful if you already own BizTalk Server for EAI and B2B purposes. You might as well leverage it as much as possible to maximise your ROI.

  8. Agent Smith says:

    Jeesh what a bunch of party poopers …. bandwidth etc is cheap compared to handling disputes around POD … the manual process is:

    (1) Customer does not pay bill

    (2) AR ring customer who claims no POD

    (3) A witch hunt ensues, trying to find the piece of paper that is the POD

    (4) Once found (after wading through filing cabinets), it is then either copied and posted or faxed to the customer

    The auto process (and yes bar coding is a good idea) is customer can be emailed the jpeg/pdf or better still, give em a self service web site ….

    We have the above, but are actually moving beyond manual POD to a hand held device that captures the signature directly and GPRSs it back to a repository whereupon it can be viewed by customers directly …

    But don’t mind me, I see technology as an enabler, not a barrier to getting things done …..


  9. Cameron Reilly says:

    moving to handheld devices is obviously the ideal outcome Agent Smith! In some situations, though, it seems to be difficult to get there. I’m thinking of our friend Agent Orange, who has outsourced his freight, and is finding it difficult to get the freigt company to get their drivers to se handhelds. Another issue seems to be theft, loss, etc of the devices. Does your company have a solutio for these problems?

  10. Agent Smith says:

    We are using mobile phones running Pocket PC … eg XDAs.

    The drivers will fund these themselves (they already need to have phones) … we leverage our buying power to offset the weekly cost of $7 on a plan by giving them much lower call rates than they could get in their own right, plus access to least cost routing etc. Automating the process saves them 30-45 minutes per day and as they get paid by the number of units delivered by a certain time of the day, they see it as a win win

    I’m not sure Agent Orange would appreciate the moniker …. or would he?

  11. Agent Smith says:

    21 days into his new CIO role, Agent Smith has been in The Matrix for the past 2 days, road showing his new IT Strategy …. he is describing EAI technology as a big powerboard that applications can plug in to in a standard way … the punters are taking the blue tablet and are ecstatic about the new future where all their apps can also plug into The Matrix.

  12. Sam says:


    Thank you for using my favorite Microsoft keyword ‘leverage’ in a sentance. I enjoy that :).

    But I still don’t understand why a client would rather pay 10K a year for Biztalk rather than 2K for a one off purchase of Visual Studio .NET.

    Biztalk isn’t THAT simple to use.

  13. Sam – okay, let me start with the usual disclaimer that this may not necessarily be the right answer for every situation, etc etc yada yada.


    The main reason I see a lot of customers moving away from custom app dev for integration solutions is that maintaining them is a hassle, slow and expensive. I see many many companies that have, over the course of 20 years, developed hundreds and hundreds of little pieces of spaghetti code to do this or that… and I’m sure it was all great code when it was first written… but time moves on, and people leave, and skills change, and then one day you find yourself with hundreds of little applications that keep your business running but the people who wrote them are long gone from the organization and nothing was written down and now? You want to upgrade your ERP. You have 200 hundred bits of dangly code hanging off of it that you have to worry about testing as well as the normal pain that goes into an ERP upgrade. It slows you down big time.

    So the current thinking seems to be: let’s stick as much of that spaghetti code as possible into BizTalk (or something like it). Of course, inside BizTalk, there may be code written to do this and that, but if you develop it properly, it is "chunked down" to specific objects, not big meaty applications, and should be easier to interpret in the future (of course, it’s always a good idea to write stuff down as well).

    There are lots of other reasons to use a piece of integration middleware as well. We’ve sunk untold millions and person-years into developing BizTalk, and hopefully some of that investment makes developers more efficient.

    You are right, Biztalk isn’t simple, but neither is developing and maintaining enterprise applications.

    In terms of the BTS vs VS.NET ROI – customers should invest in both. (hey, i bet you knew I was going to say that!). Seriously, the investment in BTS will be returned over many many projects inside a typical medium – large organisation. From EAI to B2B to Human Workflow Automation. And VS.NET will give you excellent (some would say "the best", but I’ll leave that to the marketing and sales folks) tools to develop objects for Biztalk.

    Does this make sense? I appreciate your feedback. Getting our messaging around this clear and correct is very important and that’s the main reason for my blog – to have this kind of dialogue. Thanks for helping!

  14. Sam says:

    I do understand that MS is pushing Biztalk, I just think that they are pushing it in the wrong niches sometimes, and I think this is one of them. Developing a Biztalk application to simply store scanned images is still IMHO a big waste. I would have understood this scenario better if the scanned invoice then had transfered to a manufactureer and then back again to another supplier, who all have their own formats (and maybe one is still using a IBM mainframe too).

    I can, however, see that Biztalk definetly has its uses. We ourselves invested alot of time investigating Biztalk for a project very simliar to the one you have above, but we’ve decided to save the money and do it ourselves in SQL. And we will save money (from Biztalk licenses to Biztalk developer training in the future), and time (as we don’t have to bring developers up to speed, and our application was never that compilicated anyway).

    If your target business is big enough to have ‘information anaylsts’ (or whatever they are calling them this month), then you can afford to have people creating custom Biztalk workflows in Visio, but its not realistic for 90% of the world’s companies who don’t have that sort of headcount.

  15. Agent Smith says:

    I agree that any one point solution could possible be done cheaper than an investment in Biztalk for that one point solution ….

    I had this arguement from my team when we had to do a B2B project with our largest customer. They even did the FUD on me to the extent that I agreed to a race; they could do it in RPG and I would bring in another team to run beside them using Biztalk.

    Biztalk cost me $13K on my EA plus a $10k server to run it on. Developers cost $600 per day vs $1000 per day for the RPG contractors. The RPG team also required a $10k server

    The RPG team had 4 people in it and took 3 months; cost 3 x 4 x 20 x 1000 = $240k, plus the server = $250k

    The Biztalk team had 2.5 people and took 5 months. The cost was 2.5 * 5 * 20 * 600 =$150k, plus Biztalk plus the server = $173k The reason Biztalk took longer was that we had 2 months of agony with the ERP vendors API which frankly didn’t work … they charged an additional $100k in "professional" services to sort that out (not covered by maintenance because we had a modified back end). The cost therefore was $273k.

    A win to RPG …… however …. the RPG team had massively modified the ERP with triggers in the database, stored procedures and a couple of hundred thousand lines of code in the ERP. What do you think the upgrade cost would have been? At least 50% of the cost of the original project! The Biztalk solution was a clip on/clip off module and required no additional code in the ERP.

    Once we had the Biztalk solution in place, we went on to deliver an interactive transactional web site for our farmers (being in agri-business), a B2B solution with vendors and a B2B solution with our quality testing partner. The incremental cost of each of these? $20 – %60k …. the RPG team would have cost another $200k for each.

    The difference between a CIO and an IT Manager is vision …. apologies to the IT Managers out there.

Comments are closed.

Skip to main content