Business Without Barriers - 5 things

Yahoo Archive
1
> ... I just recieved a quote for "Customization
> Maintenance" It is a flat price & will cover a 2 year period. It expires
> when either 3 patches are done or the 24 month period is over.

Hmm. Three patches and not service packs, right? I assume that is three
patches that you decide to apply and not necessarily three patches that come
out, otherwise that's about 3-6 months for 9.04, 5-12 months for 8.03, and
about a year+ for 8.0.

I understand that Epicor wants to limit the exposure. OTOH, they are the
ones in control of how often Service Packs and Patches come out. Do they
know if a patch touches your customization? Do they tell you?

Mark W.
2
After reading some recent posts, I got to thinking about the theme of the
up-coming user summits: "Business without Barriers." The last event of the
day is called: "Surviving the Downturn: What your company can do now to
improve productivity." Surely, one of the purposes of these user summits is
sell software but there is a component of users sharing knowledge like we do
here and in the EUG forums. This sharing enables companies to exploit the
resources already at hand in our current versions of the software through
the use of clever work-arounds, brilliant reporting tricks, and insightful
procedures.

Having worked for a software companies in a previous life, I understand the
challenges Epicor has trying to write code that works well with many
disparate companies. On the whole, I'd say Epicor had the right idea
creating BPMs, open Business Objects, and customizable reporting to help
make the software fit the vastly different companies that run its software.

Many organizations, including manufacturing (& software) companies, service
organizations, schools, governments, non-profits, etc., often get caught up
in their own survival and lose the sense of partnership that they must have
with the people they serve that (ironically) insures their survival.

As users, we always want Epicor to do something for us. The question is: if
you were become President/CEO of Epicor, based on what you know as a user,
what five things would you do to reduce barriers to business for your
customers? This can include software changes, procedural changes, company
strategy, business model changes, etc.

This isn't meant to be a bitch session, so please keep it positive. Think of
it as a "Software Company Summit". The top five things (1 = most important)
you would do if you were the President/CEO of Epicor:

5.

4.

3.

2.

1.
3
Epicor can't please everyone. Each manufacturing company is different. Process vs. discrete vs. make-to-order, etc... Yet they try, and end up really pleasing very few. Vantage was born of a system designed for metal fabrication job shops (remember JSCS-II and DCD-Classic?) and shined (except for being written in RPG-II on AS/400). As it was stretched to fit other settings (and expand their market base) trade-offs began to be made. We really resented having Engineering Workbench crammed down our throat. One size does NOT fit all. Granted, features in 8.x an beyond (customization, BPM, XML for Crystal, etc...) help smooth things over but they add a lot of complexity too. Most customers have limited IT resources (if someone, like the Controller, is not already doing double duty). Vantage used to be very low maintenance.

So in terms of CEO priority....
1. Modularize the base system and create specialized product pipelines for various mfg modes around a common technology base. Order Entry for Job Shops vs. Order Enter for Ship From Stock.

2. Stop the hard core emphasis on selling modules & consulting. Instead assign every customer, as part of their base maintenance cost, a "facilitator" whose objective is not revenue but to make a site succeed with the system. Forget CAMs call them "Customer Success Managers". Customers who succeed will be revenue generators without trying...those who don't, won't, ever....if they survive.

3. Develop guides (free, of course) with roadmaps for best practices. Use system experts to canvas the customer base for industry specific techniques that work best. Q&A approach...like "If your customers changes the order release delivery dates on a daily basis schedule this way...." in a big flow chart. This is an investment in customer success.

4. The CEO should never know the stock price. Only an index made up of growth in customer success (increase in gross margin $ ?) X growth in total number of system customers. This will serve the shareholders better in the long run than quarter by quarter focus.

5. The CEO should be spending several days per month at customer sites learning, one on one, what people can do with the system and what roadblocks there are to succeeding. Bring that Success Manager person along too. Then public blog what you learned, warts & all. Don't worry about the competition...have that CSM deal with the warts and blog the result too.

Sorry Mark, perhaps not exactly what you were looking for but surviving the downturn is pretty individual and the CEO has to be at a lot higher level of focus.

Just my personal views, not those of my employer.
Todd Caughey
IT Manager
Harvey Vogel Mfg. Co.

PS...we all know this group is monitored by Epicor. How about if responses to this thread were submitted to Mr. Klaus as food for thought?



________________________________

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Mark Wonsil
Sent: Thursday, April 02, 2009 7:45 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Business Without Barriers



After reading some recent posts, I got to thinking about the theme of the
up-coming user summits: "Business without Barriers." The last event of the
day is called: "Surviving the Downturn: What your company can do now to
improve productivity." Surely, one of the purposes of these user summits is
sell software but there is a component of users sharing knowledge like we do
here and in the EUG forums. This sharing enables companies to exploit the
resources already at hand in our current versions of the software through
the use of clever work-arounds, brilliant reporting tricks, and insightful
procedures.

Having worked for a software companies in a previous life, I understand the
challenges Epicor has trying to write code that works well with many
disparate companies. On the whole, I'd say Epicor had the right idea
creating BPMs, open Business Objects, and customizable reporting to help
make the software fit the vastly different companies that run its software.

Many organizations, including manufacturing (& software) companies, service
organizations, schools, governments, non-profits, etc., often get caught up
in their own survival and lose the sense of partnership that they must have
with the people they serve that (ironically) insures their survival.

As users, we always want Epicor to do something for us. The question is: if
you were become President/CEO of Epicor, based on what you know as a user,
what five things would you do to reduce barriers to business for your
customers? This can include software changes, procedural changes, company
strategy, business model changes, etc.

This isn't meant to be a bitch session, so please keep it positive. Think of
it as a "Software Company Summit". The top five things (1 = most important)
you would do if you were the President/CEO of Epicor:

5.

4.

3.

2.

1.
4
Excellent Todd. I like your 5 points and will support them as my own 5.
Nice work on this.



From: Todd Caughey [mailto:caugheyt@...]
Sent: Thursday, April 02, 2009 9:40 AM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] Business Without Barriers



Epicor can't please everyone. Each manufacturing company is different.
Process vs. discrete vs. make-to-order, etc... Yet they try, and end up
really pleasing very few. Vantage was born of a system designed for
metal fabrication job shops (remember JSCS-II and DCD-Classic?) and
shined (except for being written in RPG-II on AS/400). As it was
stretched to fit other settings (and expand their market base)
trade-offs began to be made. We really resented having Engineering
Workbench crammed down our throat. One size does NOT fit all. Granted,
features in 8.x an beyond (customization, BPM, XML for Crystal, etc...)
help smooth things over but they add a lot of complexity too. Most
customers have limited IT resources (if someone, like the Controller, is
not already doing double duty). Vantage used to be very low maintenance.

So in terms of CEO priority....
1. Modularize the base system and create specialized product pipelines
for various mfg modes around a common technology base. Order Entry for
Job Shops vs. Order Enter for Ship From Stock.

2. Stop the hard core emphasis on selling modules & consulting. Instead
assign every customer, as part of their base maintenance cost, a
"facilitator" whose objective is not revenue but to make a site succeed
with the system. Forget CAMs call them "Customer Success Managers".
Customers who succeed will be revenue generators without trying...those
who don't, won't, ever....if they survive.

3. Develop guides (free, of course) with roadmaps for best practices.
Use system experts to canvas the customer base for industry specific
techniques that work best. Q&A approach...like "If your customers
changes the order release delivery dates on a daily basis schedule this
way...." in a big flow chart. This is an investment in customer success.

4. The CEO should never know the stock price. Only an index made up of
growth in customer success (increase in gross margin $ ?) X growth in
total number of system customers. This will serve the shareholders
better in the long run than quarter by quarter focus.

5. The CEO should be spending several days per month at customer sites
learning, one on one, what people can do with the system and what
roadblocks there are to succeeding. Bring that Success Manager person
along too. Then public blog what you learned, warts & all. Don't worry
about the competition...have that CSM deal with the warts and blog the
result too.

Sorry Mark, perhaps not exactly what you were looking for but surviving
the downturn is pretty individual and the CEO has to be at a lot higher
level of focus.

Just my personal views, not those of my employer.
Todd Caughey
IT Manager
Harvey Vogel Mfg. Co.

PS...we all know this group is monitored by Epicor. How about if
responses to this thread were submitted to Mr. Klaus as food for
thought?

________________________________

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf Of Mark Wonsil
Sent: Thursday, April 02, 2009 7:45 AM
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subject: [Vantage] Business Without Barriers

After reading some recent posts, I got to thinking about the theme of
the
up-coming user summits: "Business without Barriers." The last event of
the
day is called: "Surviving the Downturn: What your company can do now to
improve productivity." Surely, one of the purposes of these user summits
is
sell software but there is a component of users sharing knowledge like
we do
here and in the EUG forums. This sharing enables companies to exploit
the
resources already at hand in our current versions of the software
through
the use of clever work-arounds, brilliant reporting tricks, and
insightful
procedures.

Having worked for a software companies in a previous life, I understand
the
challenges Epicor has trying to write code that works well with many
disparate companies. On the whole, I'd say Epicor had the right idea
creating BPMs, open Business Objects, and customizable reporting to help
make the software fit the vastly different companies that run its
software.

Many organizations, including manufacturing (& software) companies,
service
organizations, schools, governments, non-profits, etc., often get caught
up
in their own survival and lose the sense of partnership that they must
have
with the people they serve that (ironically) insures their survival.

As users, we always want Epicor to do something for us. The question is:
if
you were become President/CEO of Epicor, based on what you know as a
user,
what five things would you do to reduce barriers to business for your
customers? This can include software changes, procedural changes,
company
strategy, business model changes, etc.

This isn't meant to be a bitch session, so please keep it positive.
Think of
it as a "Software Company Summit". The top five things (1 = most
important)
you would do if you were the President/CEO of Epicor:

5.

4.

3.

2.

1.





[Non-text portions of this message have been removed]
5
> Sorry Mark, perhaps not exactly what you were looking for but surviving
> the downturn is pretty individual and the CEO has to be at a lot higher
> level of focus.

Nothing to be sorry about! That was a well-reasoned response.

> Just my personal views, not those of my employer.

I'll be working on mine tonight...

Mark W.
6
Highly inspired by Todd, here are my five things I would do if I was the
President of Epicor:

Quality
-------
Quality is top priority. There will be Unit Testing of the business objects
and separate testing for the UI. (For more information on Unit Testing see
http://www.nunit.org) EVERY support call would result in a new unit test to
prevent the same error from ever happening again in later versions of the
software. Assertions should be added to a version of the software with
assertions enabled to help debug errors.
(http://support.microsoft.com/kb/815788)

Moreover, the phrase "Works as Designed" would be stricken from daily use
and only to be uttered if and only if the software behavior was described in
marketing literature. "Worked as designed" insinuates forethought. If a
program "Works as Programmed" that doesn't mean that its logic is correct.
How many months (years?) has the scheduling system not worked? This is a
critical function for many companies as well as a major selling point of any
ERP package. It has to work right now and every time.

Support and Maintenance
-----------------------
I would decouple Support from Maintenance. Combining the two makes it so
expensive that it's the first thing that a customer drops when things get
bad. Users need support and program fixes to stay in business. Support is
like insurance, you hope you don't need it but when you need it, you really
need it. Support also means that someone comes to your plant and views the
product in action and observes any "barriers" within the solution and
reports them back to development. Support is the forefront of the
development process since they are interfacing with the customer base more
than any other department at Epicor.

Maintenance on the other hand is there to pay for upgrades to the product.
The trouble with the current policy is that users pay for development but
then have to pay for it again in new modules. Just as there are multiple
levels of support, I would have multiple levels of maintenance. One level
would provide what we offer today but another level would allow users to add
new products for the price of adding maintenance alone. I wonder how much
money was made selling new Credit Card Processing licenses compared to what
would be coming in if 750+ users added maintenance for it. I'd quit nickel
and diming users by creating arbitrary modules to artificially create new
sales.

Maintenance and support should be the driving revenue for the company. New
sales are important and will come naturally when we leverage the experiences
of our current user base to deliver a product that people actually use on a
daily basis. Concentrating on new sales alone leads to bloatware like
Microsoft Office and creates a ticked-off'd user base that feels ignored.
One negative comment takes ten positives to overcome. Keep your user base
happy and it will grow.

Custom programming will offer a maintenance program to pay for upgrades as
the product matures. No reason to pay for it again and again. Some
maintenance relief would be provided if the custom code makes it into the
standard code base.

Architecture
------------
Having to manage nine different product lines, I would continue the move to
Epicor platform utilizing the ICE framework. However, there needs to be
continuous performance improvements in the framework through better
methodologies (on-demand/partial loading of business objects, better locking
strategies, etc.)

I would also create simple data objects as primitives as a basis to make
more complex business objects. This would support modularization and
productization for various industry groups (discussed below). It would also
make it easier to move to other application servers in the future.

Any third-party programs (i.e., not written by Epicor) would be loosely
coupled so that other products could be replaced with similar products or
internal customer systems. In addition to Method Directives and Data
Directives (available in Epicor 9), I would add Action Directives to BPMs.
This would give hooks into action items like printing, MRP, Scheduling, etc.

Epicor is more technically advanced than many other ERP vendors but that
advantage would be far more valuable if the staff understood the business
needs our customers deal with on a daily basis. What good is cleverly
designed software if only a few use its functionality?

Since ICE is a .Net-based framework, I would investigate the use of the
Windows Workflow Foundation and the Windows Communication Foundation to
reduce some development costs by leveraging existing technology.

Serious consideration will be given to a standardized scripting language.
Mixing ABL, VB, C#, etc. makes it a more difficult product to manage and
train.

Reconnect with the User
-----------------------
There is a large disconnect between the developers (and to a much lesser
extent - support) and our users. As Todd mentioned, there are many types of
businesses Epicor supports (retail, electronics, MTO, CTO, distribution
centers, etc.) Each of these groups has different needs. I would create
groups of users who would discuss with the developers and support the needs
of that industry. There would be no limitation on who can participate in
these groups. These groups would meet in the field and at Perspectives. The
purpose of these groups is to pass the current industry issues onto the
Epicor Staff (Sales, Development, Support, and Administration). As the
President of Epicor, I realize that Epicor's success is directly tied to the
success of our users. The last thing users need, especially these days, is
another barrier to staying in business.

Users should know about issues that other users are having. This can only
reduce support costs and make a better product in the long run.

Consulting, Training and Documentation
--------------------------------------
Documentation is paramount to reducing support costs. The User Guides are
quite good and worth every penny but I would make an online version
available to everyone on support. Certain online training should ALWAYS be
made available for any level of support as well. (How to navigate, etc.)
Epicor should still offer customer training especially for more advanced
topics.

The consulting group should be steeped in general business practices first
(CPIM, Quality, EDI, SOX, ISO, GAAP, etc.) and then show how to implement
those ideals in the software. They should also be utilized as input into the
development process.
7
Wow you got to work fast. I just recieved a quote for "Customization Maintenance" It is a flat price & will cover a 2 year period. It expires when either 3 patches are done or the 24 month period is over.

--- In vantage@yahoogroups.com, "Mark Wonsil" <mark_wonsil@...> wrote:
>
> Highly inspired by Todd, here are my five things I would do if I was the
> President of Epicor:
>
> Quality
> -------
> Quality is top priority. There will be Unit Testing of the business objects
> and separate testing for the UI. (For more information on Unit Testing see
> http://www.nunit.org) EVERY support call would result in a new unit test to
> prevent the same error from ever happening again in later versions of the
> software. Assertions should be added to a version of the software with
> assertions enabled to help debug errors.
> (http://support.microsoft.com/kb/815788)
>
> Moreover, the phrase "Works as Designed" would be stricken from daily use
> and only to be uttered if and only if the software behavior was described in
> marketing literature. "Worked as designed" insinuates forethought. If a
> program "Works as Programmed" that doesn't mean that its logic is correct.
> How many months (years?) has the scheduling system not worked? This is a
> critical function for many companies as well as a major selling point of any
> ERP package. It has to work right now and every time.
>
> Support and Maintenance
> -----------------------
> I would decouple Support from Maintenance. Combining the two makes it so
> expensive that it's the first thing that a customer drops when things get
> bad. Users need support and program fixes to stay in business. Support is
> like insurance, you hope you don't need it but when you need it, you really
> need it. Support also means that someone comes to your plant and views the
> product in action and observes any "barriers" within the solution and
> reports them back to development. Support is the forefront of the
> development process since they are interfacing with the customer base more
> than any other department at Epicor.
>
> Maintenance on the other hand is there to pay for upgrades to the product.
> The trouble with the current policy is that users pay for development but
> then have to pay for it again in new modules. Just as there are multiple
> levels of support, I would have multiple levels of maintenance. One level
> would provide what we offer today but another level would allow users to add
> new products for the price of adding maintenance alone. I wonder how much
> money was made selling new Credit Card Processing licenses compared to what
> would be coming in if 750+ users added maintenance for it. I'd quit nickel
> and diming users by creating arbitrary modules to artificially create new
> sales.
>
> Maintenance and support should be the driving revenue for the company. New
> sales are important and will come naturally when we leverage the experiences
> of our current user base to deliver a product that people actually use on a
> daily basis. Concentrating on new sales alone leads to bloatware like
> Microsoft Office and creates a ticked-off'd user base that feels ignored.
> One negative comment takes ten positives to overcome. Keep your user base
> happy and it will grow.
>
> Custom programming will offer a maintenance program to pay for upgrades as
> the product matures. No reason to pay for it again and again. Some
> maintenance relief would be provided if the custom code makes it into the
> standard code base.
>
> Architecture
> ------------
> Having to manage nine different product lines, I would continue the move to
> Epicor platform utilizing the ICE framework. However, there needs to be
> continuous performance improvements in the framework through better
> methodologies (on-demand/partial loading of business objects, better locking
> strategies, etc.)
>
> I would also create simple data objects as primitives as a basis to make
> more complex business objects. This would support modularization and
> productization for various industry groups (discussed below). It would also
> make it easier to move to other application servers in the future.
>
> Any third-party programs (i.e., not written by Epicor) would be loosely
> coupled so that other products could be replaced with similar products or
> internal customer systems. In addition to Method Directives and Data
> Directives (available in Epicor 9), I would add Action Directives to BPMs.
> This would give hooks into action items like printing, MRP, Scheduling, etc.
>
> Epicor is more technically advanced than many other ERP vendors but that
> advantage would be far more valuable if the staff understood the business
> needs our customers deal with on a daily basis. What good is cleverly
> designed software if only a few use its functionality?
>
> Since ICE is a .Net-based framework, I would investigate the use of the
> Windows Workflow Foundation and the Windows Communication Foundation to
> reduce some development costs by leveraging existing technology.
>
> Serious consideration will be given to a standardized scripting language.
> Mixing ABL, VB, C#, etc. makes it a more difficult product to manage and
> train.
>
> Reconnect with the User
> -----------------------
> There is a large disconnect between the developers (and to a much lesser
> extent - support) and our users. As Todd mentioned, there are many types of
> businesses Epicor supports (retail, electronics, MTO, CTO, distribution
> centers, etc.) Each of these groups has different needs. I would create
> groups of users who would discuss with the developers and support the needs
> of that industry. There would be no limitation on who can participate in
> these groups. These groups would meet in the field and at Perspectives. The
> purpose of these groups is to pass the current industry issues onto the
> Epicor Staff (Sales, Development, Support, and Administration). As the
> President of Epicor, I realize that Epicor's success is directly tied to the
> success of our users. The last thing users need, especially these days, is
> another barrier to staying in business.
>
> Users should know about issues that other users are having. This can only
> reduce support costs and make a better product in the long run.
>
> Consulting, Training and Documentation
> --------------------------------------
> Documentation is paramount to reducing support costs. The User Guides are
> quite good and worth every penny but I would make an online version
> available to everyone on support. Certain online training should ALWAYS be
> made available for any level of support as well. (How to navigate, etc.)
> Epicor should still offer customer training especially for more advanced
> topics.
>
> The consulting group should be steeped in general business practices first
> (CPIM, Quality, EDI, SOX, ISO, GAAP, etc.) and then show how to implement
> those ideals in the software. They should also be utilized as input into the
> development process.
>
8
Todd & Mark,

Both of you have said it better than I could have. And yes, Todd, I DO remember JSCSII & Classic. I may be from "the old days," but the darned product was rock-solid and very crash-resistant.

My two cents.

Dan Maddox
Pactiv Corp

PS And yes, my co-workers would agree.


---- Mark Wonsil <mark_wonsil@...> wrote:
> Highly inspired by Todd, here are my five things I would do if I was the
> President of Epicor:
>
> Quality
> -------
> Quality is top priority. There will be Unit Testing of the business objects
> and separate testing for the UI. (For more information on Unit Testing see
> http://www.nunit.org) EVERY support call would result in a new unit test to
> prevent the same error from ever happening again in later versions of the
> software. Assertions should be added to a version of the software with
> assertions enabled to help debug errors.
> (http://support.microsoft.com/kb/815788)
>
> Moreover, the phrase "Works as Designed" would be stricken from daily use
> and only to be uttered if and only if the software behavior was described in
> marketing literature. "Worked as designed" insinuates forethought. If a
> program "Works as Programmed" that doesn't mean that its logic is correct.
> How many months (years?) has the scheduling system not worked? This is a
> critical function for many companies as well as a major selling point of any
> ERP package. It has to work right now and every time.
>
> Support and Maintenance
> -----------------------
> I would decouple Support from Maintenance. Combining the two makes it so
> expensive that it's the first thing that a customer drops when things get
> bad. Users need support and program fixes to stay in business. Support is
> like insurance, you hope you don't need it but when you need it, you really
> need it. Support also means that someone comes to your plant and views the
> product in action and observes any "barriers" within the solution and
> reports them back to development. Support is the forefront of the
> development process since they are interfacing with the customer base more
> than any other department at Epicor.
>
> Maintenance on the other hand is there to pay for upgrades to the product.
> The trouble with the current policy is that users pay for development but
> then have to pay for it again in new modules. Just as there are multiple
> levels of support, I would have multiple levels of maintenance. One level
> would provide what we offer today but another level would allow users to add
> new products for the price of adding maintenance alone. I wonder how much
> money was made selling new Credit Card Processing licenses compared to what
> would be coming in if 750+ users added maintenance for it. I'd quit nickel
> and diming users by creating arbitrary modules to artificially create new
> sales.
>
> Maintenance and support should be the driving revenue for the company. New
> sales are important and will come naturally when we leverage the experiences
> of our current user base to deliver a product that people actually use on a
> daily basis. Concentrating on new sales alone leads to bloatware like
> Microsoft Office and creates a ticked-off'd user base that feels ignored.
> One negative comment takes ten positives to overcome. Keep your user base
> happy and it will grow.
>
> Custom programming will offer a maintenance program to pay for upgrades as
> the product matures. No reason to pay for it again and again. Some
> maintenance relief would be provided if the custom code makes it into the
> standard code base.
>
> Architecture
> ------------
> Having to manage nine different product lines, I would continue the move to
> Epicor platform utilizing the ICE framework. However, there needs to be
> continuous performance improvements in the framework through better
> methodologies (on-demand/partial loading of business objects, better locking
> strategies, etc.)
>
> I would also create simple data objects as primitives as a basis to make
> more complex business objects. This would support modularization and
> productization for various industry groups (discussed below). It would also
> make it easier to move to other application servers in the future.
>
> Any third-party programs (i.e., not written by Epicor) would be loosely
> coupled so that other products could be replaced with similar products or
> internal customer systems. In addition to Method Directives and Data
> Directives (available in Epicor 9), I would add Action Directives to BPMs.
> This would give hooks into action items like printing, MRP, Scheduling, etc.
>
> Epicor is more technically advanced than many other ERP vendors but that
> advantage would be far more valuable if the staff understood the business
> needs our customers deal with on a daily basis. What good is cleverly
> designed software if only a few use its functionality?
>
> Since ICE is a .Net-based framework, I would investigate the use of the
> Windows Workflow Foundation and the Windows Communication Foundation to
> reduce some development costs by leveraging existing technology.
>
> Serious consideration will be given to a standardized scripting language.
> Mixing ABL, VB, C#, etc. makes it a more difficult product to manage and
> train.
>
> Reconnect with the User
> -----------------------
> There is a large disconnect between the developers (and to a much lesser
> extent - support) and our users. As Todd mentioned, there are many types of
> businesses Epicor supports (retail, electronics, MTO, CTO, distribution
> centers, etc.) Each of these groups has different needs. I would create
> groups of users who would discuss with the developers and support the needs
> of that industry. There would be no limitation on who can participate in
> these groups. These groups would meet in the field and at Perspectives. The
> purpose of these groups is to pass the current industry issues onto the
> Epicor Staff (Sales, Development, Support, and Administration). As the
> President of Epicor, I realize that Epicor's success is directly tied to the
> success of our users. The last thing users need, especially these days, is
> another barrier to staying in business.
>
> Users should know about issues that other users are having. This can only
> reduce support costs and make a better product in the long run.
>
> Consulting, Training and Documentation
> --------------------------------------
> Documentation is paramount to reducing support costs. The User Guides are
> quite good and worth every penny but I would make an online version
> available to everyone on support. Certain online training should ALWAYS be
> made available for any level of support as well. (How to navigate, etc.)
> Epicor should still offer customer training especially for more advanced
> topics.
>
> The consulting group should be steeped in general business practices first
> (CPIM, Quality, EDI, SOX, ISO, GAAP, etc.) and then show how to implement
> those ideals in the software. They should also be utilized as input into the
> development process.
>
>
>
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and Crystal Reports and other 'goodies', please goto: http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto: http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto: http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>
>
>
9
Brilliantly put Mark (and Todd for the inspiration).

I'd sign my name to the bottom of that if it were proposed to Epicor in a flash.

There are two additional things I would consider adding (one somewhat already addressed and simply requiring some verbage adjustments within the Five Things you so clearly stated) - so perhaps we should consider Six Things . (Perhaps if you agree you might attempt an amendment Mark.)

My number One would be:

Statement of Company Integrity -

Epicor vows that their primary goal is to always act with total integrity towards their perspective customers, their current customers, their vendors, their employees (direct contracted or subcontracted) and to have open, translucently shared communication between their primary internal business groups.

(The Epicor Sales group would NOT pass this test right now. I also get the impression that inside of Epicor, "the left hand doesn't know what the right hand is doing" in regard to information sharing between the internal business groups.)

- As to my last issue, perhaps somewhere in your Architecture & Reconnect With The Users section you can clarify that the bottom line need for most users is to have a clean, simple and efficient UI from which to run our businesses.

Continued progress in moving towards the ICE Framework and object oriented code base is great - but it should not be done blindly at the expense of shear UI application performance (or drive the need for expensive 'bleeding edge' continual upgrades of supporting hardware & middleware).

Epicor is clearly on a path towards the mid-market (at the expense of its original small market targeted user installations) - but that just meeans the 'heads down' performance of applications must improve even further for them to provide a product capable of handling these larger businesses that have larger entry activity work flow throughput.

(Vantage 8.03.4xx - and I would suspect 9 - is a DOG compared to other competing ERP products out there that are still based on older, but more mature, stable and optimized frameworks - and particularly compared to the character based products of just a decade and a half ago.)

Speed, simplicity, 100% up-time reliability & practical efficiency of users' time is king in small and mid-market companies - as long as it remains scalable and capable of handling growth.


Well done Mark! (and Todd!)

Rob



--- On Fri, 4/3/09, Mark Wonsil <mark_wonsil@...> wrote:
From: Mark Wonsil <mark_wonsil@...>
Subject: RE: [Vantage] Business Without Barriers - 5 things
To: vantage@yahoogroups.com
Date: Friday, April 3, 2009, 10:45 AM












Highly inspired by Todd, here are my five things I would do if I was the

President of Epicor:



Quality

-------

Quality is top priority. There will be Unit Testing of the business objects

and separate testing for the UI. (For more information on Unit Testing see

http://www.nunit. org) EVERY support call would result in a new unit test to

prevent the same error from ever happening again in later versions of the

software. Assertions should be added to a version of the software with

assertions enabled to help debug errors.

(http://support. microsoft. com/kb/)



Moreover, the phrase "Works as Designed" would be stricken from daily use

and only to be uttered if and only if the software behavior was described in

marketing literature. "Worked as designed" insinuates forethought. If a

program "Works as Programmed" that doesn't mean that its logic is correct.

How many months (years?) has the scheduling system not worked? This is a

critical function for many companies as well as a major selling point of any

ERP package. It has to work right now and every time.



Support and Maintenance

------------ --------- --

I would decouple Support from Maintenance. Combining the two makes it so

expensive that it's the first thing that a customer drops when things get

bad. Users need support and program fixes to stay in business. Support is

like insurance, you hope you don't need it but when you need it, you really

need it. Support also means that someone comes to your plant and views the

product in action and observes any "barriers" within the solution and

reports them back to development. Support is the forefront of the

development process since they are interfacing with the customer base more

than any other department at Epicor.



Maintenance on the other hand is there to pay for upgrades to the product.

The trouble with the current policy is that users pay for development but

then have to pay for it again in new modules. Just as there are multiple

levels of support, I would have multiple levels of maintenance. One level

would provide what we offer today but another level would allow users to add

new products for the price of adding maintenance alone. I wonder how much

money was made selling new Credit Card Processing licenses compared to what

would be coming in if 750+ users added maintenance for it. I'd quit nickel

and diming users by creating arbitrary modules to artificially create new

sales.



Maintenance and support should be the driving revenue for the company. New

sales are important and will come naturally when we leverage the experiences

of our current user base to deliver a product that people actually use on a

daily basis. Concentrating on new sales alone leads to bloatware like

Microsoft Office and creates a ticked-off'd user base that feels ignored.

One negative comment takes ten positives to overcome. Keep your user base

happy and it will grow.



Custom programming will offer a maintenance program to pay for upgrades as

the product matures. No reason to pay for it again and again. Some

maintenance relief would be provided if the custom code makes it into the

standard code base.



Architecture

------------

Having to manage nine different product lines, I would continue the move to

Epicor platform utilizing the ICE framework. However, there needs to be

continuous performance improvements in the framework through better

methodologies (on-demand/partial loading of business objects, better locking

strategies, etc.)



I would also create simple data objects as primitives as a basis to make

more complex business objects. This would support modularization and

productization for various industry groups (discussed below). It would also

make it easier to move to other application servers in the future.



Any third-party programs (i.e., not written by Epicor) would be loosely

coupled so that other products could be replaced with similar products or

internal customer systems. In addition to Method Directives and Data

Directives (available in Epicor 9), I would add Action Directives to BPMs.

This would give hooks into action items like printing, MRP, Scheduling, etc.



Epicor is more technically advanced than many other ERP vendors but that

advantage would be far more valuable if the staff understood the business

needs our customers deal with on a daily basis. What good is cleverly

designed software if only a few use its functionality?



Since ICE is a .Net-based framework, I would investigate the use of the

Windows Workflow Foundation and the Windows Communication Foundation to

reduce some development costs by leveraging existing technology.



Serious consideration will be given to a standardized scripting language.

Mixing ABL, VB, C#, etc. makes it a more difficult product to manage and

train.



Reconnect with the User

------------ --------- --

There is a large disconnect between the developers (and to a much lesser

extent - support) and our users. As Todd mentioned, there are many types of

businesses Epicor supports (retail, electronics, MTO, CTO, distribution

centers, etc.) Each of these groups has different needs. I would create

groups of users who would discuss with the developers and support the needs

of that industry. There would be no limitation on who can participate in

these groups. These groups would meet in the field and at Perspectives. The

purpose of these groups is to pass the current industry issues onto the

Epicor Staff (Sales, Development, Support, and Administration) . As the

President of Epicor, I realize that Epicor's success is directly tied to the

success of our users. The last thing users need, especially these days, is

another barrier to staying in business.



Users should know about issues that other users are having. This can only

reduce support costs and make a better product in the long run.



Consulting, Training and Documentation

------------ --------- --------- --------

Documentation is paramount to reducing support costs. The User Guides are

quite good and worth every penny but I would make an online version

available to everyone on support. Certain online training should ALWAYS be

made available for any level of support as well. (How to navigate, etc.)

Epicor should still offer customer training especially for more advanced

topics.



The consulting group should be steeped in general business practices first

(CPIM, Quality, EDI, SOX, ISO, GAAP, etc.) and then show how to implement

those ideals in the software. They should also be utilized as input into the

development process.