Discussion

By Robert Godwin on Feb 16, 2017

Jen- Good advice as usual. Do one thing and do it well is better for software design. Trying to be a 'Jack of all trades' leads to being a master of none.
Dealing with MS Dynamics 365 is an example of how multiple systems with very similar capabilities leads to confusion rather than clarity. Powerful, yes, but too many navigation and feature issues. It is in fact a weird system. I think of it as Swiss Army knife syndrome.

By Michael Jahn on Feb 16, 2017

Great of you to share Jen!

While I might agree that a Print MIS developer might try an avoid adding an a Laundry API, I do think there is a valid argument for the enabling modules / support for things that may not have been "why you purchased".

As a Print MIS developer - we have a constant discussion internally and externally between "that looks like mission creep" and customers asking "why can it do THIS too".

Simple example - years back - we offer a way to perform Estimates, and then enable the user to convert to a production order. That very moment "commits" an amount of substrate inventory to the job, and *sometimes* you might not have enough of that on hand, so - we were asked - can you add an inventory system ? ( SEVERAL customer were asking ) What about adding the ability to create and submit POs for the substrates and other things we sell that are NOT printed ?

Being a print service provider is complex. Lots of things to manage. As it turns out, more often than not, the support requests drive product development !