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
- Anonymous
February 13, 2004
The comment has been removed - Anonymous
February 13, 2004
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... - Anonymous
February 13, 2004
yep, got one right here for ya
http://bama.ua.edu/~hamri007/office_space/TPSreport.pdf - Anonymous
February 13, 2004
You forgot retooling and retraining´and then maintenence, licneces , and adminstering - Anonymous
February 13, 2004
And time spell checking :| - Anonymous
February 13, 2004
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! - Anonymous
February 13, 2004
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... - Anonymous
February 14, 2004
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. - Anonymous
February 16, 2004
The comment has been removed - Anonymous
February 16, 2004
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? - Anonymous
February 17, 2004
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? - Anonymous
February 17, 2004
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. - Anonymous
February 17, 2004
Cameron:
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. - Anonymous
February 18, 2004
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! - Anonymous
February 18, 2004
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. - Anonymous
February 21, 2004
The comment has been removed