Discussion

By Jim Fetherston on Nov 18, 2015

Wise words. An integration must have a stated objective and metrics to track performance. The point about asking detailed versus general questions seems basic, but is incredibly important. Problem is many people don't have the knowledge or understanding to frame the conversation by the 10 questions Jennifer lists. Do yourself a favor and write them down.

By Jennifer Matt on Nov 18, 2015

Jim - business people do know what they want and they DO NOT need to be super technical. For instance when your web-to-print order entry volume reaches a certain threshold you know you can't continue the manual entry into your Print MIS anymore (too much non-value added labor).

So the business objective can be stated: "I want web-to-print orders to flow into my Print MIS providing us with as few touches as possible from order entry to invoice."

So important to go ALL THE WAY to invoice. Don't stop with the job is auto created in the Print MIS, that is order entry, follow that job all the way through your Production Workflow and your Business Workflow. You can make small changes in the integration and cut invoicing efforts in half!

Your business has many on ramps (order entry), production off ramps (shipping physical goods, delivery digital goods) and finally the business workflow off ramp that is THE MOST IMPORTANT - an accurate invoice sent as fast as possible b/c in the end CASH fuels the whole system; without it, everyone goes home.

Sorry for the rant but I just got going...

By Steve MacKenzie on Dec 16, 2015

This subject is very near and dear to my heart, as I have been doing this for over 25 years. Jennifers right, from the Customers perspective, they are safe to state their goals at a very high level, and stay far away from the weeds. Asking questions like why? leads into a greater understanding of what problem they are trying to solve. However, from the integrators perspective usually having the need to have a project plan, and a budget with timelines, the devil is in the details. True successful integration need those details as to how to setup tables, scripts, relational data then develop log files, etc to track events and resolve unexpected (even if the integrator asked the right questions and the answer was: oh - no need to worry about that as that will never happen...) situations that take additional effort and time to properly support. Reports are a good example. It's far easier to critique a report than to design 1 from scratch. Therefore expect report development to go through several re writes as the new report goes from concept to production and more users eyes and experience. This is why Integration isn't cheap, but when done right drives automation