Kanban

If you feel you were misled by your sales team, that is a different
issue. I still say that calling that function "Kanban Receipts" is
not misleading in any way. That screen can in fact be effectively
used as one part of a Kanban process. Your requirement for longer
term planning, and the way Vantage MRP supports it, is in my opinion
a positive, not a negative. It is a good example of why many small
and mid-size manufacurers cannot adopt lean in the same way as
Toyota. Toyota can use their muscle to go to their suppliers and
dictate a just-in-time relationship where everyting they need is
available on short notice. The material can then be "pulled" as
needed. Smaller firms in many cases cannot dictate that type of
relationship, or the nature of their product mix does not allow it,
so they have to place POs for long lead time items, sometimes long
before the firm orders are received from their customers. Some type
of planning function is required for that and MRP is how it is done
in Vantage. What is your alternative for long lead time purchased
items?

As far as Epicor being purchased, the typical situation in the ERP
industry after a buyout is the opposite of what you have described.
In most cases, the buying company wants to improve cash flow and
profits quickly, so they fire most of the developers and go
into "Maintenance Mode". If you want Vantage to stay as it is with
minimal future improvements, a buyout is the best way to get there.
Right now, Epicor is engaged in a very ambitious project to combine
all of their ERP products onto a common platform which is based on
Vantage 8/9 technology. My guess is that will limit their ability
to add new functions beyond what is needed for the consolidation, in
the near term, but will be a huge benefit to Vantage users in the
long term because the user base will be much larger, and the
development resources that can be focused on Vantage will be much
larger.


--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>
> Harsh? Maybe.
>
> How is a function called "KanBan Receipts" NOT Epicor calling it
KanBan?
>
> A year ago, Epicor's sales team certainly had no qualms
promoting it is one of several Vantage capabilities that support
TPS/Lean.
>
> Many on our ERP selection team recognized it for what it really
was - but nough people on our team were duped by the slick Epicor
scripted sales process claims (of which Lean support was but one of
several 'hot button issues' swaying some key selection team members -
that proved far less true than claimed) that it very much 'swung
the vote' and won Epicor the final selection decision.
>
> I have no problem with a sales team fulfilling their roles and
winning sales. I do have a problem when the methods used to do so
have created distrust in a relationship which now must succeed for
the next 5-10 years.
>
> Yes: The KanBan Receipts function can be used to simply report
production activity triggered by actual independent demand
requirements ('pull').
>
> In our markets, customer order fulfillment of assemble to order
products is expected in days (of nearly an infinite number of
possible product final configurations). These final assemblies are
produced from about 8,000 SKUs comprised complex machined, cast,
forged and electrical components (along with simple commercial
hardware & seals).
>
> Most of our SKUs are themselves variations on several hundred
core component design families. BOMs are several levels deep to
minimize inventory by choosing to hold long lead time (2-6 month)
inventory at only specific BOM levels that have the most common
features within each family.
>
> Final component production BOM/SKU levels are typically just
machining of the final differentiating features (and post machining
finishing processes). This can be done in days/weeks versus months
for raw and semi-machined casting/forging lead times.
>
> In an environment like this, even when using KanBan Receipt at
common known non-stock sub-assembly levels (true kan-bans to support
make to order assembly flow) and at top level (specific final
machined configurations) SKUs, we (and at other companies like ours -
as in my experience, our conditions are not particularly unique)
still need long range planning for very long lead time base
purchased SKUs (of which there are hundreds and hundreds - sourced
from vendors all over the world).
>
> To manage those long lead time supply chains well, that still
requires the long range planning assistance that only MRP (or
several primary variants of MRP that have gained acceptance over the
last several decades) provides.
>
> For MRP to function several BOM levels deep below the
independent demand level (customer demand level), the BOM levels in
between must be planned levels by MRP.
>
> Therefore, just because a function like "KanBan Receipts" is
used to minimize non-value added Job creation &
scheduling/maintenance activities, the levels are still
fundamentally MRP 'push' planned levels. The MRP created Unfirmed
orders are just never Firmed.
>
> They are simply vehicles to pass planned demand & inventory
stock level targets (albeit small levels of inventory - just enough
to buffer against known demand variation patterns and still allow
fulfillment of high customer service level targets) to lower and
lower SKU levels.
>
> But it is still 'push'.
>
> As for communicating what we want to Vantage: Yes - and at every
opportunity. However, the general responses are either (simply put)
one of three:
>
> 1. Why would you want that? (In other words, they don't have a
clue.)
> 2. From Epicor/Vantage implementation consultants and
applications specialists: That is a common request (politely and
tacitly implying that, since it still hasn't been fulfilled yet,
don't expect it to be any time soon).
> 3. Would you like a Customization quote on that from our
programming group?
>
> I stand by my original email statement where I hope Vantage
becomes an attractive target for aquisition by a company that
understands manufacturing, will see the agressively growing user
installations as a ready to serve broad customer base - and utilize
the modern, increasingly .Net compliant technology program base as a
good fit for its own existing applications/technologies and
expertise.
>
> With Epicor's clear dual emphasis on agressively
expanding/growing its user base (at the cost of near term earnings
per share financial results) and aggressively 'going .Net' (instead
of less emphasis on underlying .Net conversion and more on increased
manufacturing functionality) , it seems they are doing everything
they can to make themselves a desireable aquisition target
(...perhaps for that company in Redmond - now that the US Justice
Department seems satisfied enough that they have exacted their pound
of flesh).
>
>
>
>
> Dave Thomas <dthomas@...> wrote:
> Your comments seem harsh. I don't believe Epicor calls
the process
> you describe "Kanban". The "Kanban Receipts" function in Vantage
is
> simply a way of recording production, with the associated material
> and labor consumption, without having to create a job in advance.
It
> could be used as part of a true kanban process, or in other ways.
> I don't see how that is "deception". I also don't see how that is
> necessarily a "push" system. If the production demand is being
> driven by the downstream process, not the planning functions of
the
> system, that would be "pull" wouldn't it?
>
> How do you want it to work? Have you ever communicated that to
> Epicor?
>
> --- In vantage@yahoogroups.com, Robert Brown <robertb_versa@>
> wrote:
> >
> > Bravo John.
> >
> > It is outright deception for Epicor to call their automated job
> creation, material issue, std labor backflush and automated
receipt
> process application "Kan-ban". It is simply a min o/h triggered
> inventory replenishment system for a single location (equally
> deceptively called "bin") with automation to hide the ugly details
> from the users.
> >
> > Push is still push and Vantage's so called "Kan-Ban" IS push
> (not a Lean pull system).
> >
> > One caveat to your excellent reply: Kan-ban is not necessarily
> exclusively 2-bin based. Complex mixed mode Lean production cells
> responsible for producing an array of similar parts or assemblies
> (all with different Takt times) may result in the highest Takt
time
> part/assembly best being managed with more than a simple 2 bin
> system to insure all possible parts/assemblies produced in the
cell
> can be produced within an acceptable period of time to meet
customer
> service goals.
> >
> > Similarly, material handling constraints can affect the decision
> on the number of bins to use for a part/assembly managed by
kanban.
> Bins may need to be sized so they aren't too heavy or large to
> handle with minimal material handling equipment.
> >
> > Vantage's mechanism of using an automated Job (creation,
> material issue, labor backflush & receipt) is a typical mechanism
> used by all systems claiming to be "lean" systems - but until
Epicor
> provides the built in analysis tools for determining if a
> part/assembly even requires a kan-ban (not needed if parts kan be
> produced on the fly "In Line Flow" as needed to meet Takt) - and
to
> assist in determining kan-ban sizing (qty/bin & number of bins) if
> Kan-ban buffers are needed, a Job is still a Job.
> >
> > The fact that they have not enabled their 'kan-ban' Job process
> to allow reporting of scrap (or any quality problem issues
> experienced during production) is a completely missed opportunity
to
> easily collect critical information necessary to continuously
> improve the product and the process to eliminate waste.
> >
> > Perhaps someday someone at Epicor will wake up and realize they
> have some pieces already in place to truly support Lean (with some
> tweaking)...
> >
> > But then again, this is a company that thinks "APS" is MRP (and
> can be of any benefit only using current as-scheduled supply date
> data for internal production & not also vendor in-process and in-
> transit 'real enough' time updated data).
> >
> > Hopefully, v9 will be a compelling enough technical platform
> (stable and flexible) that a company who understands manufacturing
> will acquire the product out and develop it to its true potential.
> The 'used car salesmen' Marketing types apparently driving the
show
> at Epicor right now aren't capable of it.
> >
> >
> >
> > John Sage <list@> wrote:
> > Mike McGee wrote:
> > >
> > > Our Kanban quantities are no less
> > > than a one month supply of the item.
> >
> > If this is the case, then your kanban may be as wasteful as MRP.
A
> true
> > kanban systems uses two bins. Each kanban bin should be sized
> > identically to reflect the replenishment cycle time. For example:
> >
> > Dept B uses 75 of widget XYZ per day. Widget XYZ is made by Dept
A,
> > which makes the widget once per week (per their level-load
plan).
> The
> > kanban bin size should be 5 X 75, or 375 widgets. When one bin is
> > emptied, the kanban card is delivered to Dept A, and Dept B will
> begin
> > consuming the second bin.
> >
> > However this leaves no protection from internal variation
(machine
> down,
> > absent operators, raw material stock-out, etc.). Some companies
> use 1.5
> > times replenishment cycle as the kanban bin size, so the "safer"
> bin
> > size for Widget XYZ might be 8 X 75, or 600 widgets. Much less
> costly
> > than 22 X 75 or 1650 widgets - inventory on the shelf represents
> cash
> > spent on materials and labor.
> >
> > But the real question is: Why is Widget XYZ on a kanban? Why
hasn't
> > the output of Dept A been linked directly to Dept B? There may
very
> > well be good reasons, but the objective of any lean plant is
pull,
> not
> > batch. Kanbanning sub-assemblies should only be done when it's
not
> > possible to flow them.
> >
> > Since Epicor really doesn't understand what a kanban is or how
it
> should
> > work, you'll never run lean using Vantage's tools. Vantage is
> > job-ticket, batch & queue oriented. The exact opposite of lean.
The
> > first lean principle: Make exactly what the customer wants, when
he
> > wants it, in the quantity he wants. Anything else is cash down
the
> drain.
> >
> > john
> >
> >
> >
> >
> >
> >
> > ---------------------------------
> > Take the Internet to Go: Yahoo!Go puts the Internet in your
> pocket: mail, news, photos & more.
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
> ---------------------------------
> Moody friends. Drama queens. Your life? Nope! - their life, your
story.
> Play Sims Stories at Yahoo! Games.
>
> [Non-text portions of this message have been removed]
>
For those of you using Kanban receipts...
Is anyone else frustrated by the change in the method of recording labor
between 6.0 and 6.1.
We do not use payroll, but do use Vantage to track time to send to our PR
company. In 6.0 when you used Kanban, the labor was entered in Labor entry
against the current Labor header record for the employee the Kanban is
assigned to. Now in 6.1, Kanban creates a whole new labor header for the
Kanban so it looks from labor entry as if the employee was punched in to
work twice for that day, both times for the whole shift. The response from
development was "it was an intentional change and is not intended to be
changed back".
Am I alone in my frustration with this?

Aaron Hoyt
Vantage Plastics
Is anyone using Kanban with Vantage? How do you schedule parts through production using Kanban? Can you use Kanban along with MRP? What ways are people using Vantage to support the lean manufacturing concepts? I'd appreciate any information on this.
Thanks,
Beth


---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.

[Non-text portions of this message have been removed]
We are using Kanban but not Kanban receipts in Vantage. We have not been
able to find a good way to report and track scrap and defective parts using
the Kanban receipts. We use Kanban cards to initiate demand and then set up
a job for the Kanban quantity.



Mike

Flexial Corporation

V6.1



_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Beth Castillo
Sent: Monday, August 13, 2007 9:06 AM
To: Vantage Users
Subject: [Vantage] Kanban



Is anyone using Kanban with Vantage? How do you schedule parts through
production using Kanban? Can you use Kanban along with MRP? What ways are
people using Vantage to support the lean manufacturing concepts? I'd
appreciate any information on this.
Thanks,
Beth

---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail,
news, photos & more.

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
Beth



We have whole Factories working on Kanban from Dashboards in Vantage
8.00 and 8.03 up to 5 work areas deep



Using Unfirm job demands and then booking kanbans from the dashboard
screen. This then reduces the Kanban job quantities in the order of
start date and removes it from screen eventually. It also informs the
user if the Kanban job has been created from a negative stock position.



This give a true dynamic position of demand in real time.

Gary Parfrey

Dot Net IT Limited, Reg No 4412519

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Beth Castillo
Sent: 13 August 2007 15:06
To: Vantage Users
Subject: [Vantage] Kanban



Is anyone using Kanban with Vantage? How do you schedule parts through
production using Kanban? Can you use Kanban along with MRP? What ways
are people using Vantage to support the lean manufacturing concepts? I'd
appreciate any information on this.
Thanks,
Beth

---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
mail, news, photos & more.

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
The Kanban cards tell you how many parts to make, but do they say when you need them? How do you know if the department that needs to produce these parts will have the capacity to make the parts when you need them?
Beth


Mike McGee <mmcgee@...> wrote:
We are using Kanban but not Kanban receipts in Vantage. We have not been
able to find a good way to report and track scrap and defective parts using
the Kanban receipts. We use Kanban cards to initiate demand and then set up
a job for the Kanban quantity.

Mike

Flexial Corporation

V6.1

_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Beth Castillo
Sent: Monday, August 13, 2007 9:06 AM
To: Vantage Users
Subject: [Vantage] Kanban

Is anyone using Kanban with Vantage? How do you schedule parts through
production using Kanban? Can you use Kanban along with MRP? What ways are
people using Vantage to support the lean manufacturing concepts? I'd
appreciate any information on this.
Thanks,
Beth

---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail,
news, photos & more.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]






---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.

[Non-text portions of this message have been removed]
That is determined by your kanban qty. Our Kanban quantities are no less
than a one month supply of the item. The department know that they have one
month do complete the job from date of issue. The job completion date is
one month from date of issue. Kanban only works well with repetitive items
with fairly consistent demand.



_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Beth Castillo
Sent: Monday, August 13, 2007 1:45 PM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] Kanban



The Kanban cards tell you how many parts to make, but do they say when you
need them? How do you know if the department that needs to produce these
parts will have the capacity to make the parts when you need them?
Beth


Mike McGee <mmcgee@flexial. <mailto:mmcgee%40flexial.com> com> wrote:
We are using Kanban but not Kanban receipts in Vantage. We have not been
able to find a good way to report and track scrap and defective parts using
the Kanban receipts. We use Kanban cards to initiate demand and then set up
a job for the Kanban quantity.

Mike

Flexial Corporation

V6.1

_____

From: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
[mailto:vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com] On
Behalf Of
Beth Castillo
Sent: Monday, August 13, 2007 9:06 AM
To: Vantage Users
Subject: [Vantage] Kanban

Is anyone using Kanban with Vantage? How do you schedule parts through
production using Kanban? Can you use Kanban along with MRP? What ways are
people using Vantage to support the lean manufacturing concepts? I'd
appreciate any information on this.
Thanks,
Beth

---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail,
news, photos & more.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
Mike McGee wrote:
>
> Our Kanban quantities are no less
> than a one month supply of the item.

If this is the case, then your kanban may be as wasteful as MRP. A true
kanban systems uses two bins. Each kanban bin should be sized
identically to reflect the replenishment cycle time. For example:

Dept B uses 75 of widget XYZ per day. Widget XYZ is made by Dept A,
which makes the widget once per week (per their level-load plan). The
kanban bin size should be 5 X 75, or 375 widgets. When one bin is
emptied, the kanban card is delivered to Dept A, and Dept B will begin
consuming the second bin.

However this leaves no protection from internal variation (machine down,
absent operators, raw material stock-out, etc.). Some companies use 1.5
times replenishment cycle as the kanban bin size, so the "safer" bin
size for Widget XYZ might be 8 X 75, or 600 widgets. Much less costly
than 22 X 75 or 1650 widgets - inventory on the shelf represents cash
spent on materials and labor.

But the real question is: Why is Widget XYZ on a kanban? Why hasn't
the output of Dept A been linked directly to Dept B? There may very
well be good reasons, but the objective of any lean plant is pull, not
batch. Kanbanning sub-assemblies should only be done when it's not
possible to flow them.

Since Epicor really doesn't understand what a kanban is or how it should
work, you'll never run lean using Vantage's tools. Vantage is
job-ticket, batch & queue oriented. The exact opposite of lean. The
first lean principle: Make exactly what the customer wants, when he
wants it, in the quantity he wants. Anything else is cash down the drain.

john
Bravo John.

It is outright deception for Epicor to call their automated job creation, material issue, std labor backflush and automated receipt process application "Kan-ban". It is simply a min o/h triggered inventory replenishment system for a single location (equally deceptively called "bin") with automation to hide the ugly details from the users.

Push is still push and Vantage's so called "Kan-Ban" IS push (not a Lean pull system).

One caveat to your excellent reply: Kan-ban is not necessarily exclusively 2-bin based. Complex mixed mode Lean production cells responsible for producing an array of similar parts or assemblies (all with different Takt times) may result in the highest Takt time part/assembly best being managed with more than a simple 2 bin system to insure all possible parts/assemblies produced in the cell can be produced within an acceptable period of time to meet customer service goals.

Similarly, material handling constraints can affect the decision on the number of bins to use for a part/assembly managed by kanban. Bins may need to be sized so they aren't too heavy or large to handle with minimal material handling equipment.

Vantage's mechanism of using an automated Job (creation, material issue, labor backflush & receipt) is a typical mechanism used by all systems claiming to be "lean" systems - but until Epicor provides the built in analysis tools for determining if a part/assembly even requires a kan-ban (not needed if parts kan be produced on the fly "In Line Flow" as needed to meet Takt) - and to assist in determining kan-ban sizing (qty/bin & number of bins) if Kan-ban buffers are needed, a Job is still a Job.

The fact that they have not enabled their 'kan-ban' Job process to allow reporting of scrap (or any quality problem issues experienced during production) is a completely missed opportunity to easily collect critical information necessary to continuously improve the product and the process to eliminate waste.

Perhaps someday someone at Epicor will wake up and realize they have some pieces already in place to truly support Lean (with some tweaking)...

But then again, this is a company that thinks "APS" is MRP (and can be of any benefit only using current as-scheduled supply date data for internal production & not also vendor in-process and in-transit 'real enough' time updated data).

Hopefully, v9 will be a compelling enough technical platform (stable and flexible) that a company who understands manufacturing will acquire the product out and develop it to its true potential. The 'used car salesmen' Marketing types apparently driving the show at Epicor right now aren't capable of it.



John Sage <list@...> wrote:
Mike McGee wrote:
>
> Our Kanban quantities are no less
> than a one month supply of the item.

If this is the case, then your kanban may be as wasteful as MRP. A true
kanban systems uses two bins. Each kanban bin should be sized
identically to reflect the replenishment cycle time. For example:

Dept B uses 75 of widget XYZ per day. Widget XYZ is made by Dept A,
which makes the widget once per week (per their level-load plan). The
kanban bin size should be 5 X 75, or 375 widgets. When one bin is
emptied, the kanban card is delivered to Dept A, and Dept B will begin
consuming the second bin.

However this leaves no protection from internal variation (machine down,
absent operators, raw material stock-out, etc.). Some companies use 1.5
times replenishment cycle as the kanban bin size, so the "safer" bin
size for Widget XYZ might be 8 X 75, or 600 widgets. Much less costly
than 22 X 75 or 1650 widgets - inventory on the shelf represents cash
spent on materials and labor.

But the real question is: Why is Widget XYZ on a kanban? Why hasn't
the output of Dept A been linked directly to Dept B? There may very
well be good reasons, but the objective of any lean plant is pull, not
batch. Kanbanning sub-assemblies should only be done when it's not
possible to flow them.

Since Epicor really doesn't understand what a kanban is or how it should
work, you'll never run lean using Vantage's tools. Vantage is
job-ticket, batch & queue oriented. The exact opposite of lean. The
first lean principle: Make exactly what the customer wants, when he
wants it, in the quantity he wants. Anything else is cash down the drain.

john






---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.

[Non-text portions of this message have been removed]
Your comments seem harsh. I don't believe Epicor calls the process
you describe "Kanban". The "Kanban Receipts" function in Vantage is
simply a way of recording production, with the associated material
and labor consumption, without having to create a job in advance. It
could be used as part of a true kanban process, or in other ways.
I don't see how that is "deception". I also don't see how that is
necessarily a "push" system. If the production demand is being
driven by the downstream process, not the planning functions of the
system, that would be "pull" wouldn't it?

How do you want it to work? Have you ever communicated that to
Epicor?


--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>
> Bravo John.
>
> It is outright deception for Epicor to call their automated job
creation, material issue, std labor backflush and automated receipt
process application "Kan-ban". It is simply a min o/h triggered
inventory replenishment system for a single location (equally
deceptively called "bin") with automation to hide the ugly details
from the users.
>
> Push is still push and Vantage's so called "Kan-Ban" IS push
(not a Lean pull system).
>
> One caveat to your excellent reply: Kan-ban is not necessarily
exclusively 2-bin based. Complex mixed mode Lean production cells
responsible for producing an array of similar parts or assemblies
(all with different Takt times) may result in the highest Takt time
part/assembly best being managed with more than a simple 2 bin
system to insure all possible parts/assemblies produced in the cell
can be produced within an acceptable period of time to meet customer
service goals.
>
> Similarly, material handling constraints can affect the decision
on the number of bins to use for a part/assembly managed by kanban.
Bins may need to be sized so they aren't too heavy or large to
handle with minimal material handling equipment.
>
> Vantage's mechanism of using an automated Job (creation,
material issue, labor backflush & receipt) is a typical mechanism
used by all systems claiming to be "lean" systems - but until Epicor
provides the built in analysis tools for determining if a
part/assembly even requires a kan-ban (not needed if parts kan be
produced on the fly "In Line Flow" as needed to meet Takt) - and to
assist in determining kan-ban sizing (qty/bin & number of bins) if
Kan-ban buffers are needed, a Job is still a Job.
>
> The fact that they have not enabled their 'kan-ban' Job process
to allow reporting of scrap (or any quality problem issues
experienced during production) is a completely missed opportunity to
easily collect critical information necessary to continuously
improve the product and the process to eliminate waste.
>
> Perhaps someday someone at Epicor will wake up and realize they
have some pieces already in place to truly support Lean (with some
tweaking)...
>
> But then again, this is a company that thinks "APS" is MRP (and
can be of any benefit only using current as-scheduled supply date
data for internal production & not also vendor in-process and in-
transit 'real enough' time updated data).
>
> Hopefully, v9 will be a compelling enough technical platform
(stable and flexible) that a company who understands manufacturing
will acquire the product out and develop it to its true potential.
The 'used car salesmen' Marketing types apparently driving the show
at Epicor right now aren't capable of it.
>
>
>
> John Sage <list@...> wrote:
> Mike McGee wrote:
> >
> > Our Kanban quantities are no less
> > than a one month supply of the item.
>
> If this is the case, then your kanban may be as wasteful as MRP. A
true
> kanban systems uses two bins. Each kanban bin should be sized
> identically to reflect the replenishment cycle time. For example:
>
> Dept B uses 75 of widget XYZ per day. Widget XYZ is made by Dept A,
> which makes the widget once per week (per their level-load plan).
The
> kanban bin size should be 5 X 75, or 375 widgets. When one bin is
> emptied, the kanban card is delivered to Dept A, and Dept B will
begin
> consuming the second bin.
>
> However this leaves no protection from internal variation (machine
down,
> absent operators, raw material stock-out, etc.). Some companies
use 1.5
> times replenishment cycle as the kanban bin size, so the "safer"
bin
> size for Widget XYZ might be 8 X 75, or 600 widgets. Much less
costly
> than 22 X 75 or 1650 widgets - inventory on the shelf represents
cash
> spent on materials and labor.
>
> But the real question is: Why is Widget XYZ on a kanban? Why hasn't
> the output of Dept A been linked directly to Dept B? There may very
> well be good reasons, but the objective of any lean plant is pull,
not
> batch. Kanbanning sub-assemblies should only be done when it's not
> possible to flow them.
>
> Since Epicor really doesn't understand what a kanban is or how it
should
> work, you'll never run lean using Vantage's tools. Vantage is
> job-ticket, batch & queue oriented. The exact opposite of lean. The
> first lean principle: Make exactly what the customer wants, when he
> wants it, in the quantity he wants. Anything else is cash down the
drain.
>
> john
>
>
>
>
>
>
> ---------------------------------
> Take the Internet to Go: Yahoo!Go puts the Internet in your
pocket: mail, news, photos & more.
>
> [Non-text portions of this message have been removed]
>
The real question is "How Lean do you want to be?". Vantage
definitely has room for improvement to support a 100% pure lean
operation. Many of our clients, however, want to "go lean" without
understanding exactly what they are asking. Their processes,
customers, materials, etc. don't lend themselves to a truely lean
operation. Regardless, they can gain significant improvements by
applying lean principles in specific areas.

The kanban system within Vantage is limited, but it is functional.
Depending on how it is set up, Vantage can be a "Pull" system. A
sales order can be the only trigger of activity. Again, most users
are not comfortable with the risks of a 100% demand based "Pull"
system. Just like the push for ISO9000 in the 90's, going Lean to
say you are will not reap the rewards of an entire organization
adopting a lean philosophy.

Michael Randolph
Infinity Business Consulting

mrandolph@...



--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>
> Bravo John.
>
> It is outright deception for Epicor to call their automated job
creation, material issue, std labor backflush and automated receipt
process application "Kan-ban". It is simply a min o/h triggered
inventory replenishment system for a single location (equally
deceptively called "bin") with automation to hide the ugly details
from the users.
>
> Push is still push and Vantage's so called "Kan-Ban" IS push
(not a Lean pull system).
>
> One caveat to your excellent reply: Kan-ban is not necessarily
exclusively 2-bin based. Complex mixed mode Lean production cells
responsible for producing an array of similar parts or assemblies
(all with different Takt times) may result in the highest Takt time
part/assembly best being managed with more than a simple 2 bin
system to insure all possible parts/assemblies produced in the cell
can be produced within an acceptable period of time to meet customer
service goals.
>
> Similarly, material handling constraints can affect the decision
on the number of bins to use for a part/assembly managed by kanban.
Bins may need to be sized so they aren't too heavy or large to
handle with minimal material handling equipment.
>
> Vantage's mechanism of using an automated Job (creation,
material issue, labor backflush & receipt) is a typical mechanism
used by all systems claiming to be "lean" systems - but until Epicor
provides the built in analysis tools for determining if a
part/assembly even requires a kan-ban (not needed if parts kan be
produced on the fly "In Line Flow" as needed to meet Takt) - and to
assist in determining kan-ban sizing (qty/bin & number of bins) if
Kan-ban buffers are needed, a Job is still a Job.
>
> The fact that they have not enabled their 'kan-ban' Job process
to allow reporting of scrap (or any quality problem issues
experienced during production) is a completely missed opportunity to
easily collect critical information necessary to continuously
improve the product and the process to eliminate waste.
>
> Perhaps someday someone at Epicor will wake up and realize they
have some pieces already in place to truly support Lean (with some
tweaking)...
>
> But then again, this is a company that thinks "APS" is MRP (and
can be of any benefit only using current as-scheduled supply date
data for internal production & not also vendor in-process and in-
transit 'real enough' time updated data).
>
> Hopefully, v9 will be a compelling enough technical platform
(stable and flexible) that a company who understands manufacturing
will acquire the product out and develop it to its true potential.
The 'used car salesmen' Marketing types apparently driving the show
at Epicor right now aren't capable of it.
>
>
>
> John Sage <list@...> wrote:
> Mike McGee wrote:
> >
> > Our Kanban quantities are no less
> > than a one month supply of the item.
>
> If this is the case, then your kanban may be as wasteful as MRP. A
true
> kanban systems uses two bins. Each kanban bin should be sized
> identically to reflect the replenishment cycle time. For example:
>
> Dept B uses 75 of widget XYZ per day. Widget XYZ is made by Dept A,
> which makes the widget once per week (per their level-load plan).
The
> kanban bin size should be 5 X 75, or 375 widgets. When one bin is
> emptied, the kanban card is delivered to Dept A, and Dept B will
begin
> consuming the second bin.
>
> However this leaves no protection from internal variation (machine
down,
> absent operators, raw material stock-out, etc.). Some companies
use 1.5
> times replenishment cycle as the kanban bin size, so the "safer"
bin
> size for Widget XYZ might be 8 X 75, or 600 widgets. Much less
costly
> than 22 X 75 or 1650 widgets - inventory on the shelf represents
cash
> spent on materials and labor.
>
> But the real question is: Why is Widget XYZ on a kanban? Why hasn't
> the output of Dept A been linked directly to Dept B? There may very
> well be good reasons, but the objective of any lean plant is pull,
not
> batch. Kanbanning sub-assemblies should only be done when it's not
> possible to flow them.
>
> Since Epicor really doesn't understand what a kanban is or how it
should
> work, you'll never run lean using Vantage's tools. Vantage is
> job-ticket, batch & queue oriented. The exact opposite of lean. The
> first lean principle: Make exactly what the customer wants, when he
> wants it, in the quantity he wants. Anything else is cash down the
drain.
>
> john
>
>
>
>
>
>
> ---------------------------------
> Take the Internet to Go: Yahoo!Go puts the Internet in your
pocket: mail, news, photos & more.
>
> [Non-text portions of this message have been removed]
>
ami_miker wrote:
> Their processes, customers, materials, etc. don't lend
> themselves to a truely lean operation.

And this is exactly why most lean implementations will fail. Not
because the processes don't "lend themselves to lean", but because most
persons cannot imagine how lean fits into the mental framework of "we
have to do it this way because we've always done it this way."

Any operation can become lean - all you're doing is eliminating waste
from the process and making it flow from start to finish without
stopping. Whether you're fabricating a metal cabinet, assembling an
appliance, or processing patients in a hospital emergency room.

Many people think that their operation can't do lean. But the reality
is that you can. And you can realize tremendous cost savings in
material, labor, inventory and carrying costs. We've done it. And
those cost reductions make us a much stronger competitor.

And before you dismiss it, ask yourself how it is that Toyota can build
cars in the US and still outperform domestic car makers? The answer is
not union benefits and pension burdens.

have fun,
john
Harsh? Maybe.

How is a function called "KanBan Receipts" NOT Epicor calling it KanBan?

A year ago, Epicor's sales team certainly had no qualms promoting it is one of several Vantage capabilities that support TPS/Lean.

Many on our ERP selection team recognized it for what it really was - but enough people on our team were duped by the slick Epicor scripted sales process claims (of which Lean support was but one of several 'hot button issues' swaying some key selection team members - that proved far less true than claimed) that it very much 'swung the vote' and won Epicor the final selection decision.

I have no problem with a sales team fulfilling their roles and winning sales. I do have a problem when the methods used to do so have created distrust in a relationship which now must succeed for the next 5-10 years.

Yes: The KanBan Receipts function can be used to simply report production activity triggered by actual independent demand requirements ('pull').

In our markets, customer order fulfillment of assemble to order products is expected in days (of nearly an infinite number of possible product final configurations). These final assemblies are produced from about 8,000 SKUs comprised complex machined, cast, forged and electrical components (along with simple commercial hardware & seals).

Most of our SKUs are themselves variations on several hundred core component design families. BOMs are several levels deep to minimize inventory by choosing to hold long lead time (2-6 month) inventory at only specific BOM levels that have the most common features within each family.

Final component production BOM/SKU levels are typically just machining of the final differentiating features (and post machining finishing processes). This can be done in days/weeks versus months for raw and semi-machined casting/forging lead times.

In an environment like this, even when using KanBan Receipt at common known non-stock sub-assembly levels (true kan-bans to support make to order assembly flow) and at top level (specific final machined configurations) SKUs, we (and at other companies like ours - as in my experience, our conditions are not particularly unique) still need long range planning for very long lead time base purchased SKUs (of which there are hundreds and hundreds - sourced from vendors all over the world).

To manage those long lead time supply chains well, that still requires the long range planning assistance that only MRP (or several primary variants of MRP that have gained acceptance over the last several decades) provides.

For MRP to function several BOM levels deep below the independent demand level (customer demand level), the BOM levels in between must be planned levels by MRP.

Therefore, just because a function like "KanBan Receipts" is used to minimize non-value added Job creation & scheduling/maintenance activities, the levels are still fundamentally MRP 'push' planned levels. The MRP created Unfirmed orders are just never Firmed.

They are simply vehicles to pass planned demand & inventory stock level targets (albeit small levels of inventory - just enough to buffer against known demand variation patterns and still allow fulfillment of high customer service level targets) to lower and lower SKU levels.

But it is still 'push'.

As for communicating what we want to Vantage: Yes - and at every opportunity. However, the general responses are either (simply put) one of three:

1. Why would you want that? (In other words, they don't have a clue.)
2. From Epicor/Vantage implementation consultants and applications specialists: That is a common request (politely and tacitly implying that, since it still hasn't been fulfilled yet, don't expect it to be any time soon).
3. Would you like a Customization quote on that from our programming group?

I stand by my original email statement where I hope Vantage becomes an attractive target for aquisition by a company that understands manufacturing, will see the agressively growing user installations as a ready to serve broad customer base - and utilize the modern, increasingly .Net compliant technology program base as a good fit for its own existing applications/technologies and expertise.

With Epicor's clear dual emphasis on agressively expanding/growing its user base (at the cost of near term earnings per share financial results) and aggressively 'going .Net' (instead of less emphasis on underlying .Net conversion and more on increased manufacturing functionality) , it seems they are doing everything they can to make themselves a desireable aquisition target (...perhaps for that company in Redmond - now that the US Justice Department seems satisfied enough that they have exacted their pound of flesh).




Dave Thomas <dthomas@...> wrote:
Your comments seem harsh. I don't believe Epicor calls the process
you describe "Kanban". The "Kanban Receipts" function in Vantage is
simply a way of recording production, with the associated material
and labor consumption, without having to create a job in advance. It
could be used as part of a true kanban process, or in other ways.
I don't see how that is "deception". I also don't see how that is
necessarily a "push" system. If the production demand is being
driven by the downstream process, not the planning functions of the
system, that would be "pull" wouldn't it?

How do you want it to work? Have you ever communicated that to
Epicor?

--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>
> Bravo John.
>
> It is outright deception for Epicor to call their automated job
creation, material issue, std labor backflush and automated receipt
process application "Kan-ban". It is simply a min o/h triggered
inventory replenishment system for a single location (equally
deceptively called "bin") with automation to hide the ugly details
from the users.
>
> Push is still push and Vantage's so called "Kan-Ban" IS push
(not a Lean pull system).
>
> One caveat to your excellent reply: Kan-ban is not necessarily
exclusively 2-bin based. Complex mixed mode Lean production cells
responsible for producing an array of similar parts or assemblies
(all with different Takt times) may result in the highest Takt time
part/assembly best being managed with more than a simple 2 bin
system to insure all possible parts/assemblies produced in the cell
can be produced within an acceptable period of time to meet customer
service goals.
>
> Similarly, material handling constraints can affect the decision
on the number of bins to use for a part/assembly managed by kanban.
Bins may need to be sized so they aren't too heavy or large to
handle with minimal material handling equipment.
>
> Vantage's mechanism of using an automated Job (creation,
material issue, labor backflush & receipt) is a typical mechanism
used by all systems claiming to be "lean" systems - but until Epicor
provides the built in analysis tools for determining if a
part/assembly even requires a kan-ban (not needed if parts kan be
produced on the fly "In Line Flow" as needed to meet Takt) - and to
assist in determining kan-ban sizing (qty/bin & number of bins) if
Kan-ban buffers are needed, a Job is still a Job.
>
> The fact that they have not enabled their 'kan-ban' Job process
to allow reporting of scrap (or any quality problem issues
experienced during production) is a completely missed opportunity to
easily collect critical information necessary to continuously
improve the product and the process to eliminate waste.
>
> Perhaps someday someone at Epicor will wake up and realize they
have some pieces already in place to truly support Lean (with some
tweaking)...
>
> But then again, this is a company that thinks "APS" is MRP (and
can be of any benefit only using current as-scheduled supply date
data for internal production & not also vendor in-process and in-
transit 'real enough' time updated data).
>
> Hopefully, v9 will be a compelling enough technical platform
(stable and flexible) that a company who understands manufacturing
will acquire the product out and develop it to its true potential.
The 'used car salesmen' Marketing types apparently driving the show
at Epicor right now aren't capable of it.
>
>
>
> John Sage <list@...> wrote:
> Mike McGee wrote:
> >
> > Our Kanban quantities are no less
> > than a one month supply of the item.
>
> If this is the case, then your kanban may be as wasteful as MRP. A
true
> kanban systems uses two bins. Each kanban bin should be sized
> identically to reflect the replenishment cycle time. For example:
>
> Dept B uses 75 of widget XYZ per day. Widget XYZ is made by Dept A,
> which makes the widget once per week (per their level-load plan).
The
> kanban bin size should be 5 X 75, or 375 widgets. When one bin is
> emptied, the kanban card is delivered to Dept A, and Dept B will
begin
> consuming the second bin.
>
> However this leaves no protection from internal variation (machine
down,
> absent operators, raw material stock-out, etc.). Some companies
use 1.5
> times replenishment cycle as the kanban bin size, so the "safer"
bin
> size for Widget XYZ might be 8 X 75, or 600 widgets. Much less
costly
> than 22 X 75 or 1650 widgets - inventory on the shelf represents
cash
> spent on materials and labor.
>
> But the real question is: Why is Widget XYZ on a kanban? Why hasn't
> the output of Dept A been linked directly to Dept B? There may very
> well be good reasons, but the objective of any lean plant is pull,
not
> batch. Kanbanning sub-assemblies should only be done when it's not
> possible to flow them.
>
> Since Epicor really doesn't understand what a kanban is or how it
should
> work, you'll never run lean using Vantage's tools. Vantage is
> job-ticket, batch & queue oriented. The exact opposite of lean. The
> first lean principle: Make exactly what the customer wants, when he
> wants it, in the quantity he wants. Anything else is cash down the
drain.
>
> john
>
>
>
>
>
>
> ---------------------------------
> Take the Internet to Go: Yahoo!Go puts the Internet in your
pocket: mail, news, photos & more.
>
> [Non-text portions of this message have been removed]
>






---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.

[Non-text portions of this message have been removed]
--- In vantage@yahoogroups.com, John Sage <list@...> wrote:
> And before you dismiss it, ask yourself how it is that Toyota can
build cars in the US and still outperform domestic car makers? The
answer is not union benefits and pension burdens.
>
> have fun,
> john
>

I did not intend for my previous comments to be taken as arguements
against lean. The lean principles have the potential to improve
quality and production costs in just about any manufacturing
environment. That being said, a mass production operation, like
Toyota, has different challenges than a job shop. You can
successfully use the same lean principles with, but the application
will be different.

The points I was trying to make are that
(a) many companies try to go lean overnight, unsuccessfully manage
the culture change and dismiss it as a fad and
(b) Vantage has the capability to support a lean operation.

Could Vantage make improvements to be a better lean system?
Absolutely. Name a ERP that doesn't have it's weaknesses. A
company has to consider the critical features required in its
business system. As much as Epicor would love to make the sell, I
don't think "The Big Three" (or Toyota, for that matter) are good
canidates for Vantage. They have different system (and lean)
requirements than a $100M mix-mode manufacturer or a $5M job shop.

Michael Randolph
Infinity Business Consulting
mrandolph@...