How do you handle providing industry-specific solutions?

paintb4707

I was just curious how you all go about providing industry-specific solutions for your employer.

I work for a vitamin manufacturer and I'm currently responsible for implementing a Dynamics GP integrated EDI and ADC solution for our warehouse. I barely know anything about the manufacturing industry considering I'm in my own essence as the sole IT. I almost feel completely clueless as to what will or won't work for us. I sometimes get a little frustrated because I usually need my General Manager to chime in to assist me with finding the absolute best solution for our needs. I wish that I could be more independent and not need to get anyone else involved. I would like to say, this is the EDI solution I chose and this is how much it's going to cost.

Am I wrong for getting my GM involved with such projects or should I request a formal training on the industry?

sthomas

You may want to ask other IT Pros who work in Manufacturing on what they use. I did a google search and came up with this.....

http://www.microsoft.com/dynamics/gp/product/default.mspx

Not sure if this what you are looking for but may be worth looking into. In my opinion you can't go wrong with Microsoft.

I would not think getting your GM involved would be a bad thing. The job of and IT Pro is to implement and support technology but you will sometimes need someone to tell you what they want to do with the technology if that makes any sense.

astorrs

If you are responsible for implementing a piece of your companies ERP system, it is absolutely essential that you involve key individuals from the business who can help you evaluate the various products/options and what will/will not work for your company. Many ERP implementations come in way over budget (due to changes required post-implementation to fix things that were missed earlier) or fail miserably because of insufficient time spent in the planning stage.

A few questions:

How large is this company?

Do you have any experience in business analysis (i.e., gathering user requirements, documenting business processes, etc)?

Are you being asked to select the solution, or has one already been chosen and you are being asked to implement it?

Is there a consultant/vendor involved?

paintb4707

astorrs wrote:

If you are responsible for implementing a piece of your companies ERP system, it is absolutely essential that you involve key individuals from the business who can help you evaluate the various products/options and what will/will not work for your company. Many ERP implementations come in way over budget (due to changes required post-implementation to fix things that were missed earlier) or fail miserably because of insufficient time spent in the planning stage.

A few questions:

How large is this company?

Do you have any experience in business analysis (i.e., gathering user requirements, documenting business processes, etc)?

Are you being asked to select the solution, or has one already been chosen and you are being asked to implement it?

Is there a consultant/vendor involved?

I should have mentioned that we already have Dynamics GP. However we are considering moving from the proprietary inventory software that we use now and into GP. Ultimately thereafter, we are looking to be EDI compliant and also integrate ADC with GP to lessen manual errors.

Company has about 300 employees, about 50 of them are in the office and the rest are in the warehouse.

Specifically I do not. However I do feel as if I have picked up a few things when it comes to assessing our needs and supplying a solution from an IT stand-point. Not necessarily business in broad terms.

Both. I'm asked to select a solution and implement it.

There will be one consultant involved with providing his input as to whether or not Dynamics GP inventory will handle our needs as a vitamin manufacturer. The EDI and ADC are completely on me.

astorrs

It sounds like you guys aren't planning on doing an RFP for this, so here is how I would approach it:

Create a small team consisting of yourself and 2 individuals familiar with the current inventory/warehouse processes in use at your company (they should be somewhat senior, say a supervisor in the warehouse - not a recent hire! - but still have hands on familiarity with the process). Sit down with them for an day/afternoon and jointly compile a list of requirements in a matrix format. Determine which are the "must" haves (aka deal breakers), "should" haves, "would be nice to" haves, etc in any solution.

Then plot the products you have identified to see how they fit into that matrix. Compile a list of questions you can't answer on your own and contact the vendor/reseller with them and have them respond to each. Make sure to make notes about how each solution does or doesn't match a piece of criteria if its not a simple Yes/No.

For example, if one of the criteria rows is "Supports inventory/product numbers in the following 11 digit format: AAAAnnnnnnn" (4 letters followed by 7 numbers)"

These might be some of the answers (in the columns):

Product A: No, only supports 12 digit numeric only
Product B: Yes, fully supported
Product C: No, supports 11 digit alpha-numeric

The importance of this detail is when evaluating them as a whole solution you may see that product A is really the best fit in most areas but doesn't meet that one key requirement. Since your team has the "why" it doesn't work at their fingertips, you may decide it is better to choose "A" and switch to a 12 digit numeric code.

Once you have mapped out the matrix, recall your team and review it with them, especially any of the things you were unsure about. See if you can form a consensus about one of the solutions and what you all see as the problems (if any) with that solution. If you can't reach a consensus or none seems like a good fit, you may need to evalulate additional products.

Once you are all in agreement, either write up your recommendation (and the "why") in a memo /short brief to the GM or do a quick 30-60 minute presentation as to why you're picking that one. Get buy in from him then move onto the design/piloting stage.

If your having trouble getting buy in to pull these key users away from "real work" to plan with you, remind your GM that making poor choices in the planning stage of this could have serious impact on your companies ability to inventory and ship product in the future. If the people involved in choosing the solution don't understand the processes as they exist now, the company may be forced to change its business processes to accommodate the software (change to business processes is not a bad thing, but it's always disruptive and should be planned so as to benefit not detract). A couple of days of their time now could equal weeks saved in post-implementation problems.

As for training in how the business works, that's always a good thing for IT - in fact, it should be required. Michael Keen (a colleague of mine and well respected IT architect) wrote a good article over the weekend on exactly this: http://www.brianmadden.com/blog/MichaelKeen/Get-to-ITBusiness-alignment-to-ITBusiness-integration

I hope that all makes sense.

Andrew

paintb4707

astorrs wrote:

It sounds like you guys aren't planning on doing an RFP for this, so here is how I would approach it:

Create a small team consisting of yourself and 2 individuals familiar with the current inventory/warehouse processes in use at your company (they should be somewhat senior, say a supervisor in the warehouse - not a recent hire! - but still have hands on familiarity with the process). Sit down with them for an day/afternoon and jointly compile a list of requirements in a matrix format. Determine which are the "must" haves (aka deal breakers), "should" haves, "would be nice to" haves, etc in any solution.

Then plot the products you have identified to see how they fit into that matrix. Compile a list of questions you can't answer on your own and contact the vendor/reseller with them and have them respond to each. Make sure to make notes about how each solution does or doesn't match a piece of criteria if its not a simple Yes/No.

For example, if one of the criteria rows is "Supports inventory/product numbers in the following 11 digit format: AAAAnnnnnnn" (4 letters followed by 7 numbers)"

These might be some of the answers (in the columns):

Product A: No, only supports 12 digit numeric only
Product B: Yes, fully supported
Product C: No, supports 11 digit alpha-numeric

The importance of this detail is when evaluating them as a whole solution you may see that product A is really the best fit in most areas but doesn't meet that one key requirement. Since your team has the "why" it doesn't work at their fingertips, you may decide it is better to choose "A" and switch to a 12 digit numeric code.

Once you have mapped out the matrix, recall your team and review it with them, especially any of the things you were unsure about. See if you can form a consensus about one of the solutions and what you all see as the problems (if any) with that solution. If you can't reach a consensus or none seems like a good fit, you may need to evalulate additional products.

Once you are all in agreement, either write up your recommendation (and the "why") in a memo /short brief to the GM or do a quick 30-60 minute presentation as to why you're picking that one. Get buy in from him then move onto the design/piloting stage.

If your having trouble getting buy in to pull these key users away from "real work" to plan with you, remind your GM that making poor choices in the planning stage of this could have serious impact on your companies ability to inventory and ship product in the future. If the people involved in choosing the solution don't understand the processes as they exist now, the company may be forced to change its business processes to accommodate the software (change to business processes is not a bad thing, but it's always disruptive and should be planned so as to benefit not detract). A couple of days of their time now could equal weeks saved in post-implementation problems.

As for training in how the business works, that's always a good thing for IT - in fact, it should be required. Michael Keen (a colleague of mine and well respected IT architect) wrote a good article over the weekend on exactly this: http://www.brianmadden.com/blog/MichaelKeen/Get-to-ITBusiness-alignment-to-ITBusiness-integration

I hope that all makes sense.

Andrew

Thanks a lot for the suggestions. That article was very interesting as well.